What are liveness, readiness, and startup probes, and why do you need all three?

Think of these three probes like three different health checks for a restaurant kitchen. The liveness probe is a fire safety inspector who checks if the kitchen is on fire (is the application fundamentally broken?). If yes, evacuate and reset (restart the container). The readiness probe is the front-of-house manager who checks if the kitchen can take new orders right now (is the application ready for traffic?). If the kitchen is temporarily overwhelmed (processing a large batch), the manager stops seating new customers but doesn't shut down the kitchen. The startup probe is the building inspector who gives the initial certificate of occupancy (has the application finished its first-time initialization?). Until the building passes inspection, neither the fire inspector nor the front-of-house manager even starts their checks.

Liveness probes answer: 'Is this container's main process hopelessly stuck?' If the liveness probe fails (returns non-200 for HTTP, non-zero for exec, or can't connect for TCP) for failureThreshold consecutive checks, the kubelet kills the container and creates a new one. This catches scenarios where the process is running but non-functional: a Java app in a deadlock, a Python app stuck in an infinite loop consuming 100% CPU on one thread but not processing any requests, or a Node.js event loop blocked by synchronous I/O. Without liveness probes, these zombie containers would sit there forever — technically 'running' but serving no requests.

Readiness probes answer: 'Can this container handle traffic right now?' If the readiness probe fails, the Pod is removed from all Service Endpoints — no new traffic is routed to it, but the container is NOT restarted. This is the correct response for temporary conditions: the app is warming its cache, processing a large batch job, waiting for a transient dependency, or draining existing requests during shutdown. During rolling updates, readiness probes are the critical gate — new Pods must pass readiness before old Pods are terminated. Without readiness probes, Kubernetes sends traffic to Pods the instant their container starts, before they're actually ready to serve.

Startup probes solve a specific problem: slow-starting applications. Consider a legacy Java application that takes 90 seconds to start (loading Spring context, pre-populating caches, running database migrations). If you configure a liveness probe with failureThreshold=3 and periodSeconds=10, the liveness probe starts checking after initialDelaySeconds and kills the container after 30 seconds of failures — long before the app finishes starting. You could set initialDelaySeconds=120 on the liveness probe, but then you'd have a 120-second blind spot where a genuinely stuck container isn't detected. Startup probes solve this cleanly: they run ONLY during startup with a generous timeout (say, failureThreshold=30, periodSeconds=10 = 5 minutes to start), and once they succeed, they hand off to liveness/readiness probes which use tighter intervals.

The interaction between probes during a rolling update is critical: a new Pod is created → startup probe runs (liveness and readiness are disabled) → startup succeeds → readiness probe starts → readiness passes → Pod added to Service Endpoints → Deployment controller sees Pod is Ready → old Pod is terminated. If any probe in this chain fails, the rollout stalls (which is exactly what you want — don't kill old working Pods until new ones are proven healthy).

The most dangerous production gotcha: making liveness probes check external dependencies. If your liveness probe calls the database and the database is briefly unavailable, ALL Pods restart simultaneously — a cascading failure that turns a temporary database blip into a full application outage. Liveness probes should check ONLY internal application health (can the process respond at all?). Readiness probes may check dependencies (because removing traffic is safe), but even that should be done cautiously.