Liveness vs Readiness vs Startup Probes
Kubernetes health probes allow the kubelet to monitor container lifecycle states and automate recovery. Confusing liveness, readiness, and startup probes is a common cause of cascading outages in production Kubernetes clusters, as each probe triggers fundamentally different operational responses when it fails.
Liveness Probe
Deadlock Recovery & Container Restart Mechanism
Strengths
- •Automatically recovers containers stuck in unrecoverable deadlocks or infinite loops
- •Enforces self-healing by triggering a container kill and restart via the kubelet
- •Runs continuously throughout the entire container execution lifecycle
Weaknesses
- •If configured improperly, causes cascading cluster restarts during database or cache outages
- •Does not stop client traffic from hitting an overloaded or initializing container
Best For:
Detecting internal fatal deadlocks where the process is running but unable to make progress.
Readiness Probe
Traffic Routing Gate & Availability Signal
Strengths
- •Controls whether the Pod IP is included in Kubernetes Service Endpoints and Ingress routing
- •Prevents user traffic from hitting initializing, saturated, or warming containers
- •Does not kill or restart the container when temporary failures occur
Weaknesses
- •Does not restart containers that have permanently frozen or deadlocked
- •If every pod fails readiness at once, the Service has no endpoints: connections are refused, and ingress controllers typically answer HTTP 503
Best For:
Signaling whether a container is ready to process incoming network requests, including cache warm-up and transient dependency checks.
Startup Probe
Slow Initialization & Warm-Up Protection
Strengths
- •Disables liveness and readiness probe evaluation until initial startup succeeds
- •Protects slow-starting legacy apps or batch tasks from being prematurely killed by liveness probes
- •Allows long initial timeouts without slowing down subsequent steady-state failure detection
Weaknesses
- •Only runs during container boot; does nothing once the application has successfully started
- •If the application hangs permanently during boot, delays restart until failureThreshold expires
Best For:
Legacy applications, complex JVM frameworks, or containers that run one-time schema checks or heavy cache loading on launch.
Feature Comparison
| Aspect | Liveness Probe | Readiness Probe | Startup Probe |
|---|---|---|---|
| Action on Failure | Kubelet kills and restarts container (triggers restartCount++) | Pod IP removed from Service endpoints (no traffic routed) | Kubelet kills and restarts container if timeout is exceeded |
| Primary Purpose | Recover from deadlocks and hung processes (a process that exits is restarted by restartPolicy, no probe needed) | Protect pods from traffic during initialization or overload | Allow slow-starting applications extra time to initialize safely |
| Evaluation Window | Continuous after startup probe succeeds | Continuous after startup probe succeeds | Only at container launch until first successful check |
| Impact on Service Endpoints | Pod remains in Service until killed or readiness also fails | Pod immediately removed from Service routing pool | Pod not in Service routing pool during startup |
| Recommended Check Type | Shallow internal health check (no external dependency calls) | Verification that local caches and required connections are ready | Verification that the process listening socket is bound and ready |
Architecture Rule of Thumb
Explain the dangerous anti-pattern of linking liveness probes to external dependencies. If a microservice liveness probe checks downstream database connectivity and the database experiences an outage, all microservice pods will fail liveness simultaneously. The kubelet will restart every pod in a continuous crash loop, worsening the incident. Check external dependencies in readiness probes, and restrict liveness probes to internal process health.
Common Mistakes
- •Checking downstream databases or third-party APIs inside a liveness probe.
- •Relying on high initialDelaySeconds instead of a startup probe for slow-starting applications.
- •Assuming readiness probe failures restart the container (readiness only alters traffic routing).
Related Topics
That's where we come in.
Being able to explain when you would choose Liveness Probe or Readiness Probe or Startup Probe is different from reading a comparison table.
Kernelry helps you rehearse technical questions, evidence-led debugging, safe next steps, and the clear communication teams expect. The drills adapt to your answer, so you practice the reasoning rather than memorize a company-specific script. During early access, free accounts include ten daily scenarios across our mixed question pool, with no credit card required.