Kubernetes Health Probes Done Right: Liveness, Readiness, and Startup

Here's the article: Your health check endpoint returns 200 OK while your app serves 500s to every real request. Sound familiar? Most health checks are useless. They confirm the process is running — something your orchestrator already knows. A real health check system needs three distinct probes, each answering a different question. Three Probes, Three Questions Liveness : "Is this process stuck?" — If no, kill it and restart. Readiness : "Can this instance handle traffic?" — If no, stop sending requests. Startup : "Has this instance finished initializing?" — If no, wait before checking liveness. They are not interchangeable. Mixing them up causes cascading failures. What Each Probe Should (and Should NOT) Check Probe Should Check Should NOT Check Liveness Event loop responsive, no deadlock Database connectivity, downstream services Readiness DB connected, migrations done, cache warm External third-party APIs Startup Config loaded, DB pool created, initial cache fill Anything that shoul