Liveness and readiness tell Kubernetes how the Pod feels

Wed, 14 Jul 2027 00:00:00 +0000

A slow start is not a dead process: readiness shields traffic while liveness only cares about keeping the process alive. Teams wire a single HTTP endpoint into both probes, and then every slow dependency becomes a restart loop — the app needs time, liveness refuses to grant it. Two probes exist because “not ready” and “dead” demand opposite responses: one asks for time, the other for a restart.

The mental model that prevents the confusion is a hospital triage. Readiness is the waiting-room nurse deciding who sees a doctor right now; liveness is the crash cart, rolled out only when the patient codes. You would never defibrillate someone for sitting in the waiting room. Keep that image and the probe configuration almost writes itself.

Readiness gates traffic

A readiness probe failure removes the Pod from the Service’s endpoints but leaves it running, so the process can finish warming up or recover on its own. Traffic flows again as soon as the probe passes. This makes readiness the safe probe to fail: caches can warm, migrations can finish, downstream dependencies can come back, all without losing the Pod’s in-memory state or paying a restart penalty.

Design the readiness endpoint around genuine servability. Check what makes this Pod able to answer correctly right now: migrations applied, required caches populated, critical downstream reachable. A probe that only checks “the HTTP server responds” admits traffic to Pods that will fail every request. But resist stuffing every dependency into it: if a non-critical recommendation service is down, failing readiness sheds real traffic over a decoration.

Liveness guards the process

A failing liveness probe triggers a restart, a last resort that ends a hopeless wedge. Use it for what it is a liveness issue—not for containers that are merely slow to become ready. The legitimate targets are narrow: deadlocks where no request will ever succeed again, runaway goroutine or thread leaks that only a fresh process clears, corrupted in-memory state that no retry can heal. In each case the defining property is irreversibility — without a restart, recovery is impossible, not merely slow.

That bar means many services should ship a minimal liveness probe or none at all. A liveness check against an external database turns every database blip into a fleet-wide restart storm. Prefer a cheap local check — a watchdog timestamp refreshed by the main loop — that detects “this process is wedged” without consulting anything outside the process. Kubernetes already restarts crashed containers; liveness exists only for the living dead.

Give the probes grace

Set the initialDelaySeconds high enough that a cold start is not counted as a crash, and keep timeoutSeconds consistent with real work. Separate the two probes so a slow pod is protected by readiness, not mistakenly recycled by liveness. Better still, add a startup probe for slow-booting containers: while it runs, liveness stays disabled, so version upgrades that warm large caches get minutes instead of seconds without weakening steady-state liveness at all.

Tune thresholds from observed behavior, not round numbers copied between services. periodSeconds times failureThreshold is the real reaction time — 10 seconds times 3 means 30 seconds of badness before action. Measure cold-start p99, dependency recovery time, and worst-case pauses, then set each number to react faster than the alert but slower than the noise.

When it breaks

The signature failure is the restart loop during dependency outages: the database slows, readiness would have sufficed, but liveness probes share the same failing endpoint and the whole fleet restarts in waves. Each restart wipes warm caches, making the next wave slower to recover, until the system oscillates indefinitely. Diagnose by correlating restart timestamps with the dependency incident; the fix is splitting the endpoints — readiness checks the dependency, liveness checks only the process — so a sick downstream sheds traffic instead of killing Pods.

The mirror failure is the zombie Pod: liveness passes because the HTTP server responds, but every request hangs behind a deadlocked worker pool. Traffic keeps flowing to a Pod that answers nothing. The fix is a liveness endpoint that exercises the real path — acquire a worker slot with a short timeout, verify the last successful request timestamp is fresh — so wedged state fails the probe while mere slowness does not.

Check it quickly

Inspect probe wiring and recent kills:

kubectl get pod web-0 -o jsonpath='{.spec.containers[*].livenessProbe}{"\n"}{.spec.containers[*].readinessProbe}{"\n"}'
kubectl get events --field-selector reason=Unhealthy --sort-by=.lastTimestamp | tail -n 10
kubectl describe pod web-0 | grep -A3 -i 'liveness\|readiness'

Shared endpoints across both probes, or Unhealthy events coinciding with downstream incidents, mark the split that still needs doing.

Sources

Kubernetes probes, Official docs on liveness and readiness, checked 2026-06-01.
Configure liveness and readiness probes, task guide for probe configuration, checked 2026-09-05.