harshaA health endpoint can return a reassuring response while the application cannot perform its useful function. The endpoint is working; the promise behind it is underspecified.
Kubernetes separates startup, readiness, and liveness probes. Readiness influences whether a pod receives traffic, while liveness can trigger a restart. These distinctions are central to choosing meaningful checks. The Kubernetes probe documentation explains their behavior.
Ask different questions
Startup asks whether the application has finished beginning. Readiness asks whether it can accept work now. Liveness asks whether restarting the process is an appropriate response to its condition.
Those questions should not automatically use the same test. A dependency outage may make a service temporarily unable to fulfill some requests without making a restart useful. Repeated restarts can add disruption to a condition the process cannot fix.
An expensive readiness check can also become part of the workload it is meant to protect. The check should be purposeful and bounded.
Define the useful function
For an illustrative API, readiness might depend on configuration being loaded and the minimum required resources being available. For a worker, health may involve its ability to make progress rather than its ability to answer an HTTP request.
The right signal depends on the service. Copying a health endpoint from another project can copy the wrong assumption about what healthy means.
I would document each check's consequence alongside its implementation. That makes it easier to review whether a failure should remove traffic, restart a container, or alert an operator.
Test the failure behavior
A deployment test should include slow startup, temporary dependency failure, and a process that remains alive but stops doing useful work. The important observation is what the platform does in response.
Rollouts also need a clear connection between readiness and user-visible availability. A passing probe should mean enough to justify sending the next request.
Health checks are small pieces of code with large operational consequences. Their value comes from a specific promise: this signal means this service can do this kind of work, and this failure warrants this response. That promise deserves more attention than a generic “OK.”