Continuing from my last post where I used one of my favourite Interview questions to explain a concept/feature on Kubernetes.
This time around I have a different question that tests your understanding of Kubernetes health checks.Ponder on the question below for a while before scrolling down.
Imagine you have an application running on Kubernetes that has the following characteristics/requirements:
- On startup it takes 300-600 seconds to become ready because it must load a large amount of data from remote storage.
- Once running, you want fast detection of failures. An unresponsive pod should be restarted quickly
- During rollouts, pods occasionally get stuck in restart loops, even though nothing is actually wrong, they’re just still initializing.
How would you configure Kubernetes health probes for this workload?
A short Primer on Kubernetes Health Checks (Probes)
Before we get to an answer, a brief explanation of the various types of health checks provided by Kubernetes is in order.
Kubernetes supports three types of probes:
• startupProbe (if configured): Gates the entire startup phase. Until this probe succeeds, Kubernetes does not evaluate liveness or readiness.
• readinessProbe: Tells Kubernetes whether a pod should receive traffic. Failing readiness removes the pod from service but does not restart it.
• livenessProbe: Tells Kubernetes whether a container should be restarted. Failing liveness means “kill and retry.”
The makings of a 'perfect' answer:
A strong candidate will immediately notice that the workload has two conflicting characteristics:
a slow, stateful startup
a need for fast failure detection once running.
The ideal configuration pairs a patient, forgiving startupProbe with an aggressive livenessProbe and a clear readinessProbe.
Your ‘Final’ answer:
Wait for startup with a startupProbe
The application can expose a single /ready endpoint that reports whether it is fully initialised.
A startupProbe configured against this endpoint allows the application to take its full 300–600 seconds to initialise without being penalised. While the startup probe is failing, Kubernetes will not evaluate liveness or readiness, preventing premature restarts.
Failing fast with a livenessProbe
Once startup succeeds, to facilitate fast detection of genuine failures, a relatively aggressive livenessProbe can be configured so that if the process becomes unresponsive, the pod is restarted quickly.
Failover gracefully using a readynessProbe
Finally, a readinessProbe can be configured that hits the same /ready endpoint, but is evaluated continuously once startup has completed.
During startup, that endpoint naturally reports “not ready”. After startup succeeds, the readiness probe ensures the pod is only included when it can actually serve traffic, and is cleanly removed during partial failures or degraded states without triggering restarts.
Cherry on top (Bonus points guaranteed)
Bonus points if the candidate explicitly calls out why relying on initialDelaySeconds instead of a startupProbe is brittle.
initialDelaySeconds forces you to guess how long initialisation might take. In this case, startup time varies widely (300–600 seconds). Any fixed delay risks being either too short, causing restart loops or unnecessarily long, masking real failures.
So there you go. If you ever face a scenario like this in an interview or in production this mental model will serve you well.