Define health checks that reflect real service readiness

A health endpoint that always returns success can make an unavailable function look healthy. An endpoint that fails whenever any dependency slows down can create a different operational problem. Start by deciding what the check controls. A check that restarts a process needs a different question from a check that decides whether the process should receive customer requests.

Separate three operational decisions

In Kubernetes, a Pod with containers that report not ready does not receive traffic through Kubernetes Services.[6] Readiness therefore concerns whether an instance should receive that traffic. The documentation also explains how a startup probe allows initialization before the liveness probe takes over.[6] Do not collapse these distinct decisions into a single unexplained green light.

For your service, describe what must work before an instance can accept its supported requests. Then identify failures that a restart could reasonably address. Keep these descriptions tied to actual behavior rather than a generic list of every connected component.

Choose dependency checks deliberately

Recommend checking only dependencies whose failure makes the instance unable to serve the relevant workload. If an optional analytics destination fails, the core service may still support its main task. If a required authorization function is unavailable, the traffic decision may be different.

Document the dependency policy and the intended degraded mode. A deep check on every request can require additional resources, while a shallow check may miss a critical failure. Test the chosen balance with controlled conditions and agree who may change thresholds or timing.

A readiness result describes the check’s scope, not every customer journey. Keep user-facing verification alongside infrastructure health. If customers still fail while health remains green, review whether the check asks the wrong question or whether the failure sits outside its boundary.

Complex checks can also become difficult to maintain. Prefer a small, explained decision over an exhaustive endpoint that nobody trusts. Approve the design when the team can predict the control action for each tested condition and explain the remaining blind spots.

Hypothetical example: a search service warms up

In this hypothetical example, a search instance starts its process before its index is ready. A basic process check succeeds, yet customer searches cannot complete. The team gives initialization its own allowance and keeps the instance out of service until the required index is available.

It separately tests a failed optional reporting connection. That failure does not automatically make search unavailable. The example illustrates a policy choice, not a portable configuration or a promise that all searches will succeed.

Test the transitions, not just success

Ask for evidence of how an instance enters service, leaves service, and returns after a fault.

• State what each check controls: startup, restart, or traffic.
• List mandatory dependencies for the supported request.
• Test slow initialization and temporary dependency failure.
• Verify that recovery returns the instance to the intended state.
• Keep sensitive diagnostic details out of public health responses.