Liveness Probe vs Readiness Probe: Kubernetes Health Checks Compared

Mon, 03 Aug 2026 05:22:16 +0900

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

Health-Checks on IT Comparison

Liveness Probe vs Readiness Probe: Kubernetes Health Checks Compared

Overview

Comparison Diagram

Comparison Table

Key Differences

When to Use Each