Gateway Gus saysHealth checks let infrastructure know if a service is alive (liveness) and ready (readiness).
Orchestrators poll health endpoints. Liveness ("am I alive?") — if it fails, restart the instance. Readiness ("can I serve traffic?") — if it fails, stop routing to it until dependencies (DB, cache) are up. Separating them prevents restarting a healthy-but-warming-up service and avoids sending traffic to one that isn't ready.
Power-ups you unlock
Liveness: alive? → restart if failing
Readiness: ready to serve? → route only if passing
Separate concerns: don’t restart a warming service
Standard in Kubernetes and load balancers
Timeout Titan attacks — common mistakes
Conflating liveness and readiness
A health check that doesn’t check real dependencies
Heavy health checks that themselves cause load
Boss battleDecide which check should fail while a service waits for its database.
Example code
<!doctype html><html><head><meta charset="utf-8"></head>
<body style="background:#06040d;color:#e6e0ff;font-family:monospace;padding:20px"><pre>GET /healthz (liveness) → 200 = don’t restart me
GET /readyz (readiness) → 503 while DB connecting
→ no traffic until ready, but no restart</pre></body></html>