A dependency check in the liveness probe turns one outage into two

The failure is correlated, which is what decides the blast radius. Ten replicas do not hold ten private opinions about a billing database; they reach the same one. Wire that reachability into the liveness path and they all return 503 inside the same polling window, and the kubelet does the rest. The dev.to write-up states the outcome without decoration: one problem becomes two, lost capacity plus a restart storm ^[3].

The restart is also least affordable at exactly that moment. Whatever startup does, it does again. In the sample application, startup is where the pricing rules are loaded and validated ^[5], and readiness stays false until the active rule version can actually be evaluated ^[12]. A pod that was merely cut off from a dependency had all of that work already banked. A pod that was killed has to redo it, then re-earn readiness, while the dependency it was waiting for is still down. The alternative costs nothing structural: a readiness failure removes the pod from matching Service endpoints and leaves the container running ^[6].

There is a second reason the split holds. Kubernetes runs neither liveness nor readiness until the startup probe succeeds ^[4], so a slow cold start cannot be interpreted as a dead process ^[2]. That is bought at a price the piece is honest about: a startup window set too generously delays detection of a process that will never initialize at all, which is why the window should come from observed cold-start distributions rather than a copied constant ^[5].

That leaves liveness with one job, conditions a restart can repair. An event loop that no longer advances qualifies. An unreachable billing database does not, because the fresh process reaches the same database ^[7]. In the sample, readiness gates on three conditions including dependency state, liveness gates on one and never touches the dependency ^[1], and liveness makes no network calls at all ^[9]. The event loop delay threshold there is 250 ms mean, which the author flags as example policy rather than a Node.js limit ^[11].

The logging half of this is the same discipline pointed at your telemetry. Success is 204 with no body, because the kubelet needs a status and not a diagnostic document ^[9]; the health endpoints sit on their own listener on port 3001 ^[13]. If routine probe traffic stays out of application logging and you measure state transitions instead of counting every passing check ^[1], your request rate stops tracking kubelet configuration and the moment a pod went unready remains legible afterwards. That legibility is the only way anyone reconstructs a lockstep restart the next morning.

The residual risk is real and the piece names it: a narrow check will miss some degraded states, and the recommended answer is alerting on degradation through metrics rather than widening liveness ^[8]. The asymmetry is what settles it. Missing a degraded state costs one pod's worth of quality until an alert fires. A broad liveness check that reads shared infrastructure costs every pod at once ^[3], and it charges that cost precisely when capacity is already short.