Not ready or actually stuck? One health check cannot make every decision

Technical source: Kubernetes’ official probe documentation. The design proposal is independent, not ready-to-use configuration.

“Can the application accept traffic?” differs from “Is it stuck enough to require restarting?” Combining them can turn a brief problem into a wider outage.

Define separate roles

• Readiness informs traffic admission.
• Liveness detects conditions that execution policy may answer with a restart.
• Startup concerns the time an application needs to initialize.

Do not transfer those meanings blindly to every environment. Another tool’s unhealthy label does not necessarily trigger the same action; read its policy.

A hypothetical example

A database briefly disappears. If every connection failure fails liveness, healthy applications may restart repeatedly. Losing warmed-up application state can make the dependency problem worse.

I suggest keeping unnecessary dependencies out of the hard liveness decision. Readiness should reflect actual service requirements rather than only an open port.

Before enabling checks

Test slow startup, overload and temporary dependency loss in a test environment. Measure the probe’s own cost too. Document success criteria, waiting period and alert ownership.

Related reading: service health beyond ping.

Source checked: November 2, 2026. The example is hypothetical; no universal threshold or restart recommendation is given.