Kubernetes Health Checks: Liveness, Readiness, and Startup Probes

WHY IT EXISTS Without health checks, an orchestrator like Kubernetes only knows if a process is running, not if it's actually working. A web server can be running but stuck in a deadlock, unable to serve requests. Health checks solve this by providing a deeper, application-aware signal of health, enabling true automated recovery.

THE MENTAL MODEL Think of Kubernetes as a manager talking to your application pod. It asks three questions. Liveness: "Are you okay? Should I restart you?" Readiness: "Are you ready for work? Should I send you users?" Startup: "Are you still getting ready? I'll wait before I start asking other questions." This prevents Kubernetes from killing a slow-booting app or sending traffic to one that's not ready.

HOW IT WORKS Kubernetes periodically runs a "probe" against a container. There are three types of probes: Liveness, Readiness, and Startup. Each probe can be performed in one of three ways: an HTTP GET request to an endpoint (expecting a 2xx-3xx status), a TCP check on a port (seeing if it's open), or an Exec command run inside the container (expecting a zero exit code). If a probe fails a configured number of times, Kubernetes takes action: a failed Liveness probe restarts the container, while a failed Readiness probe removes it from the service load balancer until it passes again.

WHEN TO USE IT Always use health probes for long-running services like APIs or web servers. Use a Readiness probe to prevent traffic during initialization, when loading data, or when temporarily busy. Use a Liveness probe to restart a container that has entered a deadlocked or unrecoverable state. Use a Startup probe for applications with a long startup time, to avoid them being killed by an aggressive Liveness probe before they are fully initialized.

WHEN NOT TO USE IT Do not use a Liveness probe for tasks that run to completion and terminate, like a batch job. The biggest footgun is making a Liveness probe depend on external services (like a database). If the database is down, Kubernetes might restart all your app pods, causing a cascading failure. A probe should check the health of the container itself, not its dependencies.

ONE CANONICAL EXAMPLE A web application defines a Readiness probe on an HTTP endpoint /readyz. When deploying a new version, Kubernetes waits for this endpoint to return 200 OK before adding the new pod to the service's load balancer. It also has a Liveness probe on /healthz. If the app's memory leaks and it becomes unresponsive, the /healthz endpoint will stop responding, causing Kubernetes to restart the faulty container automatically.