Liveness Probe vs Readiness Probe: Kubernetes Health Checks Compared
Overview Kubernetes uses liveness and readiness probes to answer two different questions about a running container: is it alive, and is it ready to serve requests. A failed liveness probe triggers a container restart, while a failed readiness probe only affects traffic routing by pulling the pod out of Service endpoints without killing it. Comparison Diagram Liveness ProbeReadiness ProbeContainerkubelet: is it alive?Fails?yesKill & Restart ContainernostaysrunningNo effect on Service trafficContainerkubelet: is it ready?Ready?yesAdded to Service EndpointsnoRemoved(not killed)Service / Load Balancer Comparison Table Aspect Liveness Probe Readiness Probe Core question Is the process still functioning? Is the process ready to accept traffic? Action on failure kubelet kills and restarts the container Container is left running, no restart Effect on Service endpoints None directly; pod may keep receiving traffic until restart completes Pod is removed from Service endpoints, stops receiving traffic Effect on rolling deployments Not consulted for rollout progress Must pass before the pod counts as available and rollout proceeds Restart count impact Increments the container restart count on each failure Never causes a restart Typical checks used Lightweight self-check for hangs or deadlocks Checks dependency health: DB connections, cache warm-up, config load Misconfiguration risk Too-aggressive thresholds cause restart loops (CrashLoopBackOff) Too-aggressive thresholds pull healthy pods out of rotation, cutting capacity Key Differences Liveness failure causes a container restart; readiness failure only removes the pod from Service endpoints. Liveness answers “is it alive,” readiness answers “is it ready for traffic.” Readiness gates rolling deployments; liveness has no say in rollout progress. Using a dependency check as a liveness probe risks a restart loop when the real problem is an external service, not the process. When to Use Each Liveness Probe ...