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
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
- Detecting Deadlocks: A liveness probe catches a process that is technically running but internally stuck, and forces a restart to recover it.
- Self-Healing Long-Running Services: For processes prone to gradual state corruption (memory leaks, stuck threads), a periodic liveness check keeps the workload self-repairing without manual intervention.
- Guarding Against Silent Hangs: A minimal endpoint that just confirms the event loop or main thread still responds is enough to catch hangs that a crash wouldn’t otherwise surface.
Readiness Probe
- Slow Startup / Cache Warm-up: A readiness probe keeps a pod out of rotation until it finishes loading data or establishing connections, preventing early requests from failing.
- Temporary Dependency Outage: If a downstream database briefly drops, readiness lets the pod stop receiving traffic without being killed and restarted for a problem it can’t fix by restarting.
- Zero-Downtime Rolling Deployments: Readiness gates when a new pod is considered available, so the rollout only shifts traffic once the replacement is actually able to serve it.