Liveness and readiness checks

What it is

Orchestrators and load balancers probe services. Kubernetes defines liveness probes (failure restarts the container), readiness probes (failure removes the pod from service endpoints) and startup probes (delay the others until the application has started). The same distinction applies to Docker health checks and reverse-proxy health checks.

Why it matters

A liveness check that depends on the database restarts a healthy process during a database outage, making things worse. A readiness check that only checks the process sends traffic to an instance that cannot serve because its migrations have not run.

How to apply

• Liveness: the process is alive and its event loop responds; nothing external.
• Readiness: the dependencies needed to serve a request are reachable and the schema version matches; report unready during start-up and shutdown.
• Return cheap, unauthenticated responses on dedicated paths, without logging every probe as a request.
• Keep probe intervals and failure thresholds consistent with how long a real recovery takes.

Pitfalls

Readiness checks that call every dependency on every probe can overload them. Health endpoints must not expose configuration details. Probes with tight timeouts on a loaded system create flapping.