Readiness vs Liveness: Two Probes, Two Different Decisions
Readiness decides whether an instance receives traffic; liveness decides whether it should be restarted. Conflating them causes outages that are hard to diagnose.
Definition
A readiness probe reports whether an instance can accept traffic now, and a failed probe removes it from load balancing without restarting it. A liveness probe reports whether the process is stuck in a state it cannot recover from, and a failure triggers a restart.
Context and scope
Kubernetes, Nomad, and most orchestrators expose both signals, and the common single-endpoint pattern quietly maps them to the same behavior.
Common misconceptions
- Both probes should hit the same endpoint — they answer different questions and need different thresholds
- Liveness should check dependencies — that turns a shared dependency failure into a restart storm
- Startup is just slow readiness — slow starters need a startup probe or a longer initial delay
Anti-patterns
- Restarting pods because a downstream API is briefly unavailable
- Readiness checks that always pass, so traffic reaches instances before caches warm
- Identical failure thresholds and periods for both probes
Related concepts
Authoritative source
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
Two questions, not one
Readiness asks: can this instance serve traffic at this moment? Liveness asks: is this process in a state it cannot recover from without a restart? A database migration, a cold cache, or a saturated queue makes an instance not ready but perfectly alive. Restarting it would erase the warm-up progress and start over.
What each failure should trigger
A failed readiness probe removes the endpoint from load balancing. The process keeps running, keeps retrying, and rejoins when it recovers. A failed liveness probe kills and restarts the container. That is a blunt instrument, and it should only fire for deadlocks, exhausted threads, or unrecoverable state.
For example, a service that loses its database connection should fail readiness, not liveness. If liveness also fails, every replica restarts at once, the database sees a connection storm, and recovery takes longer than the original incident.
The startup case
Slow-starting applications need a third signal. A startup probe suspends liveness evaluation until the application has finished initializing, which prevents a restart loop during a long warm-up. Without it, teams stretch the initial delay until liveness becomes useless during steady state.
Compared to a single health endpoint
One endpoint is simpler to operate and is adequate for small services with no dependencies. The cost appears during partial failures, when the only options are to restart healthy-but-unready instances or to route traffic to them anyway. Splitting the signals costs a little configuration and buys precise, reversible responses.
Getting thresholds right
Tune readiness to be fast and tolerant of transient downstream errors, and liveness to be slow and strict about local health. Verify both during a deploy: readiness should gate traffic within seconds, while liveness should never fire during a normal rollout.