Comparisons
Pairs that get conflated in real conversations, and a few that get treated as synonyms when one is a prerequisite for the other. Neither column wins — what decides is the change in front of you. Each record leads with the confusion, because the confusion is why the record exists.
Readiness vs Liveness
The classic mistake is pointing both at the same handler, usually one that checks downstream dependencies. When the database has a bad minute, readiness correctly removes the instance from the load balancer — and liveness, checking the same thing, restarts every instance simultaneously, converting a dependency blip into a full outage with cold caches and a thundering herd. Liveness must test only the process itself; anything it can be wrong about, it will restart.
Use readiness to answer "should this instance receive traffic right now" — startup not finished, cache warming, or a temporary refusal to take work.
Use liveness to answer "is this process irrecoverably stuck, such that restarting it is the only fix".
| Dimension | Readiness | Liveness |
|---|---|---|
| Question | Can I serve traffic now? | Am I unrecoverable without a restart? |
| Failure action | Removed from the load balancer, keeps running | Killed and restarted |
| May check dependencies | Sometimes, carefully — and never for the whole fleet at once | No. Never. |
| Cost of a false positive | Reduced capacity | A restart storm across the fleet |
| Also needed | A startup grace period so slow boots are not mistaken for failure | A threshold high enough that a slow GC pause does not qualify |
| Non-Kubernetes equivalent | Load balancer health check controlling target registration | Process supervisor or instance health check controlling replacement |