Kubernetes liveness, readiness, startup probes done right

Stop routing traffic to pods that aren't ready and restarts that make outages worse — the three probes explained.

Kubernetes knows your container process is running. It does not know whether your app can serve traffic, whether it is wedged in a deadlock, or whether it is still warming a 90-second cache. That gap is what probes fill — but only if you pick the right probe for the right job. Readiness gates Service endpoints. Liveness triggers a container restart. Startup delays the other two until a slow-booting process is actually up. Swap readiness and liveness and a database blip becomes a fleet-wide restart.

The rule that saves most teams: readiness may check dependencies; liveness must not. If your liveness handler pings Postgres and Postgres hiccups, kubelet kills every replica at once — a self-inflicted outage that looks like an infrastructure incident. For JVM and .NET apps that need a minute to start, a startup probe prevents liveness from murdering the pod on boot. The Kubernetes administration track walks through probes in the context of rollouts and Service routing.

Readiness vs liveness — different consequences

Readiness failing during a rolling update is normal and desirable — the new pod is not ready yet, so traffic stays on the old replicas. Liveness failing during an update is a incident — kubelet keeps restarting the new pod before it ever joins the Service.

readinessProbe:
  httpGet: { path: /ready, port: 8080 }
  periodSeconds: 5
  failureThreshold: 3
livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 10
  failureThreshold: 3
  timeoutSeconds: 2

Startup probe for slow boots

Without a startup probe, liveness and readiness begin immediately. A JVM that needs 60 seconds to warm will fail liveness three times in 30 seconds and enter CrashLoopBackOff before it ever serves a request. A startup probe tells kubelet: do not run liveness or readiness until this succeeds, or until failureThreshold × periodSeconds elapses.

startupProbe:
  httpGet: { path: /healthz, port: 8080 }
  failureThreshold: 30
  periodSeconds: 5        # up to 150s boot window
livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 10

Verify probe behavior under failure

Test the negative paths deliberately. Block readiness and confirm the pod drops from Endpoints but does not restart. Break liveness locally (not via a shared dependency) and confirm a single restart, not a loop. During rollouts, watch kubectl get endpoints — ready count should climb smoothly, not oscillate.

Where this goes next

Probes keep traffic honest during rollouts; they do not replace resource limits or security context. Next: PodDisruptionBudgets so node drains respect your minimum available count, and preStop hooks so SIGTERM drains in-flight requests before readiness fails. The Kubernetes administration path covers probes, rollouts, and running workloads reliably.

Related posts