When you write a health check for a service, what should it actually be checking?
Strong answers split liveness from readiness by blast radius, restart storms versus shed traffic, and design each probe backward from its failure modes
So a health check is just an endpoint the platform polls to decide whether your instance is healthy, and the common setup splits it in two. Liveness answers, is the process alive. If it fails, the orchestrator restarts the pod. Readiness answers, can this instance serve traffic right now. If that fails, the instance drops out of the load balancer rotation but keeps running. The liveness one should be a cheap check that the process responds. Readiness can go further and verify that dependencies like the database or the cache are reachable, since serving without them would only produce errors anyway. You keep the endpoints fast, unauthenticated, and off to the side of normal routing. In Kubernetes these map to livenessProbe and readinessProbe, plus there's a startupProbe for apps that boot slowly.