A new application instance opens its network port and the platform starts sending it traffic. Its reference data is still loading, configuration has not been validated, and the first user receives an error. A minute later it may work perfectly. Why send people to it before then?
A health check is an input to an infrastructure decision. A green response alone proves very little. The useful questions are what condition was checked and what the platform will do when that condition fails.
Three checks, three different consequences
Liveness helps identify a condition from which the process cannot recover on its own, such as a stuck request handler. Repeated failure beyond a configured threshold can trigger a container restart. The signal should therefore identify something a restart can plausibly fix, rather than simply report that errors exist.
Readiness indicates whether the instance should receive new user work. A process may be functioning but not ready, or temporarily unable to serve its intended operation. Removing it from ordinary traffic is different from restarting it and does not necessarily terminate established connections.
Startup allows time for initial preparation. With a startup probe configured, Kubernetes waits for it to succeed before running liveness and readiness probes. Startup still needs a limit, after which failure is handled according to the restart policy. The Kubernetes probe documentation describes these behaviours; another platform may use different names or actions.
What will restarting fix when the supplier is down?
Imagine a liveness check calling an external tariff service. The supplier stops responding, every instance is classified as broken and the platform restarts them. The supplier has not recovered. The application has merely lost warm state and is rebuilding connections under the same demand.
A dependency can belong in diagnostics without its failure implying that the process itself is broken. Using one deep check for both traffic removal and restart combines two different decisions under a signal that may justify neither.
Readiness requires more judgement. If one instance loses its own connection to a required database, routing to other instances makes sense. If the database is unavailable to all of them, excluding every target will not repair it. Decide whether the product should reject a critical operation, preserve unaffected functions or stop accepting traffic entirely. “Never check dependencies” is not a universal rule either.
Keep the check cheap, but meaningful
A static OK page may still respond while the real handler is stuck. Yet replaying a full customer journey for every platform probe can consume connections and compete with the customers it is supposed to protect.
Separate frequent local readiness checks from deeper diagnostics. The frequent check should be quick, time-bounded and related to the instance's actual ability to serve requests. Dependency investigation can run separately at another frequency. Do not accidentally create real orders or alter production records just to prove that a process is healthy.
Consider aggregate check traffic across instances and monitoring systems. Individually cheap checks can add up. Public responses also do not need to expose internal hostnames, credentials or detailed connection errors.
Deployment is a sequence, not a switch
Prepare a new instance before admitting traffic. A departing instance stops accepting new requests and finishes accepted work within a defined period. Readiness changes do not propagate instantly, so the application must handle the transition itself as well.
One failed probe is not necessarily a sustained failure. Thresholds, intervals and timeouts should reflect normal pauses. Aggressive settings may remove capacity precisely when remaining instances are struggling; permissive settings may leave a broken instance serving requests for too long.
The probe configuration guide explains the controls. The management-level acceptance criterion is simpler: a routine deployment should not generate a burst of customer errors because capacity enters or leaves service at the wrong moment.
Healthy instances can still run a broken product
Correct readiness does not prove that purchasing, search or approval succeeds end to end. Monitor actual customer outcomes and use separate journey tests. A failed journey should not automatically restart every application: the cause may be shared configuration or data.
Test slow startup, a single instance losing a dependency, a shared supplier outage and a locally stuck process separately. Expect different, appropriate responses. If all four trigger the same mass restart, the automation is not distinguishing failure causes. It is simply repeating one action quickly.