Why Splitting Health Checks into Liveness and Readiness Prevents Restart Loops

Using a single health endpoint in containerised services can cause orchestrators like Kubernetes to restart healthy pods during brief database slowdowns. The fix involves splitting health checks into two distinct probes: liveness, which confirms the process itself is functional, and readiness, which verifies that the service can currently handle traffic. A liveness endpoint should only check internal process state, while a readiness endpoint should validate external dependencies like databases and caches, returning a 503 if any critical check fails. Readiness probes should use short timeouts and run checks in parallel to avoid hanging probes, which are more disruptive than failing ones. An IETF draft standard for health check response formatting also offers a reusable structure that monitoring tools can parse consistently across services.