What Is a Liveness Probe? Restarting Stuck Containers
A liveness probe is a periodic health check Kubernetes uses to decide whether a container is hung and should be restarted.
A process can be running yet wedged - deadlocked, stuck in an infinite loop, unable to recover. From the outside it looks alive but serves nothing. A liveness probe gives Kubernetes a way to detect that and automatically restart the container, turning a stuck app into a self-healing one.
How it works
You define a probe (HTTP, TCP, or command) that Kubernetes runs on an interval. If it fails enough consecutive times, Kubernetes kills the container and restarts it according to the pod’s restart policy.
Liveness vs readiness
Readiness controls traffic; liveness controls restarts. A pod can be live but not ready (still warming up) - so the two probes serve different jobs and are often both defined.
Avoiding restart loops
- Set an initial delay so slow starts are not killed prematurely.
- Make the probe cheap and independent of downstream services.
- A too-aggressive probe causes crash loops - tune thresholds carefully.
A common pitfall
If a liveness probe depends on a database that is temporarily down, every pod restarts together and nothing recovers. Keep liveness checks local to the process; use readiness for dependency health.
The reliability parallel
Liveness probes embody self-healing: detect a stuck workload and recover automatically. Managed CI runners apply the same philosophy to jobs - automatically recovering from transient and resource failures instead of leaving them stuck.
Key takeaways
- A liveness probe restarts a container that is running but hung.
- Liveness controls restarts; readiness controls traffic - use both.
- Keep probes cheap and local to avoid synchronized restart loops.