Kubernetes
readinessProbe vs livenessProbe
Short answer
Readiness controls whether traffic is sent to a pod. Liveness controls whether the container is restarted. Getting them the wrong way round is how a slow-starting application ends up in a restart loop.
In simple terms
Two different questions, asked repeatedly. Readiness asks “should I send requests here right now?” and the only consequence of a no is that the pod is taken out of the Service's endpoint list. Liveness asks “is this container beyond saving?” and the consequence of a no is a restart.
So readiness failing is routine and safe — it happens on every start-up, and during any period when the application is temporarily unable to serve. Liveness failing is not routine. It kills the container.
The rule that follows: if a condition might resolve on its own, that is a readiness concern. Only use liveness for states a restart genuinely fixes, like a deadlock the process cannot recover from.
What actually happens
Both are run by the kubelet on the node, not by the control plane. A readiness failure causes the pod's `Ready` condition to go false, and the endpoint controller removes its address from the Service, so traffic stops. Nothing else happens — the container keeps running and keeps being probed.
A liveness failure past `failureThreshold` causes the kubelet to kill the container. The restart counter increments, and the backoff is exponential, which is where `CrashLoopBackOff` comes from.
`startupProbe` exists specifically to separate these concerns. While a startup probe is running, liveness and readiness are both suspended, so a slow start cannot be mistaken for a hang. If you find yourself setting a large `initialDelaySeconds` on liveness, a startup probe is what you actually wanted.
Probes that will not fight each other
# Give start-up its own probe so a slow boot is not read as a hang.
startupProbe:
httpGet: { path: /healthz, port: 8080 }
failureThreshold: 30
periodSeconds: 2 # allows up to 60s to start
readinessProbe:
httpGet: { path: /ready, port: 8080 }
periodSeconds: 5 # cheap; may include dependency checks
livenessProbe:
httpGet: { path: /healthz, port: 8080 }
periodSeconds: 20
failureThreshold: 3 # ~60s of failure before a restartNote the two different paths. /ready may check that the database is reachable; /healthz must not. A liveness probe that fails when a dependency is down will restart a perfectly healthy container, repeatedly, for a problem it cannot fix.
◑ The mistake this causes
Pointing the liveness probe at an endpoint that checks dependencies.
Why people do it It seems more thorough. If the database is down, the application cannot work, so surely it is unhealthy? But liveness answers “would a restart help?”, and restarting your API does not fix someone else's database.
What you see A dependency has a brief outage and your entire fleet restarts simultaneously — turning a partial degradation into a total one, and adding a thundering herd of reconnections at exactly the moment the dependency is struggling. Restart counts climb across every pod at once, which is the signature of a shared cause rather than a pod-level fault.
How it shows up in production
The most common version has nothing to do with dependencies. An application takes 40 seconds to start — JIT warm-up, migrations, a cache load. The liveness probe has `initialDelaySeconds: 10`. So at 10 seconds the probe fails, at 30 seconds the kubelet kills the container, and it starts again from zero.
It never gets far enough to become healthy, and the restart loop is caused entirely by the probe. The logs show a clean start-up sequence cut off mid-way with no error, which is a genuinely confusing thing to look at: nothing is wrong with the application, and nothing in its output says so.
How to tell which one you are hitting
- Is the restart count climbing with no error in the logs?
- Suspect the liveness probe. Check `kubectl describe pod` for `Liveness probe failed` events, and compare the probe's timing against how long start-up actually takes.
- Did every pod restart at roughly the same moment?
- A pod-level fault does not synchronise. Simultaneous restarts across a fleet point at a shared dependency being checked by liveness.
- Does the pod work when you remove the liveness probe?
- A decisive test in a non-production namespace. If it becomes healthy, the probe was the fault and the fix is timing or a startupProbe, not the application.
How this gets asked in an interviewpreparation
Usually phrased as “What is the difference between a readiness and a liveness probe?”
What a strong answer contains Give the consequence of each failing rather than the definition: readiness removes the pod from Service endpoints, liveness restarts the container. Then state the rule — if the condition might resolve on its own, it is readiness — and mention startupProbe as the correct tool for slow starts.
The follow-up “What happens if the liveness probe checks the database?” is the follow-up worth being ready for, because the answer is a fleet-wide restart during a dependency outage.
What comes next
Did this get you to an answer?
No text box on purpose — please do not paste production logs anywhere