Liveness and readiness probes let Kubernetes make informed decisions about container health and traffic routing — correctly configured, they significantly improve application reliability. This guide covers setting them up properly.
Liveness vs Readiness: The Key Distinction
| Probe Type | Question It Answers | Action on Failure |
|---|---|---|
| Liveness | Is the container in a state requiring restart? | Kubernetes restarts the container |
| Readiness | Is the container ready to receive traffic? | Pod removed from service endpoints (not restarted) |
Why Both Matter Separately
A container might be genuinely alive (no need to restart) but temporarily not ready for traffic (still warming up, or temporarily overloaded) — conflating these into a single probe type leads to either unnecessary restarts or serving traffic to genuinely unready pods.
Basic HTTP Liveness Probe
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
periodSeconds: 20initialDelaySeconds gives the application time to start before the first check — a common source of the crash-debugging scenario in How to Debug a Crashing Pod in Kubernetes when set too aggressively short.
Basic HTTP Readiness Probe
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 10Implementing a Meaningful Health Check Endpoint
app.get('/healthz', (req, res) => res.status(200).send('OK'));
app.get('/ready', async (req, res) => {
try {
await db.query('SELECT 1');
res.status(200).send('Ready');
} catch {
res.status(503).send('Not Ready');
}
});A liveness check should be simple/fast (just confirming the process isn't deadlocked); a readiness check can be more thorough, verifying genuine dependencies (database connectivity, for example) are actually available.
Avoiding a Common Mistake: Liveness Checking Dependencies
A liveness probe that checks database connectivity is problematic — if the database is temporarily down, Kubernetes would restart the application repeatedly (which won't fix a database outage), potentially making the situation worse; reserve dependency checks for readiness, not liveness.
TCP and Command-Based Probes (Alternatives to HTTP)
livenessProbe:
tcpSocket:
port: 5432livenessProbe:
exec:
command: ["cat", "/tmp/healthy"]For applications without an HTTP endpoint, TCP socket checks or command execution provide alternative probe mechanisms.
Tuning Probe Timing Appropriately
livenessProbe:
initialDelaySeconds: 30
periodSeconds: 10
failureThreshold: 3
timeoutSeconds: 5failureThreshold requires multiple consecutive failures before action is taken — avoids overreacting to a single transient blip; tune based on your application's genuine startup time and normal response characteristics.
Using Startup Probes for Slow-Starting Applications
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30
periodSeconds: 10For applications with genuinely slow startup, a dedicated startup probe (with more lenient timing) runs before liveness/readiness probes take over, avoiding the need to set an overly generous initialDelaySeconds on your regular probes.
Common Errors
Pod repeatedly restarts despite the application seeming to work fine — almost always indicates an overly aggressive liveness probe configuration; increase initialDelaySeconds and failureThreshold, and verify your liveness endpoint genuinely reflects "needs restart" rather than transient conditions.
Continue Reading
- How to Debug a Crashing Pod in Kubernetes
- Kubernetes Pods, Deployments & Services Explained
- How to Set Up Rolling Updates and Rollbacks in Kubernetes
Browse more articles in Kubernetes & Container Orchestration.
