Liveness probe failed: The kubelet decided the container is unhealthy and restarted it

A failing liveness probe makes the kubelet kill and restart the container. It is the only probe that destroys anything, which makes a misconfigured one actively harmful rather than merely noisy.

Applies to: All Kubernetes versions

What it means

A liveness probe answers one question: should this container be restarted? When the probe fails failureThreshold times in a row, the kubelet kills the container and the restart policy takes over. That is the whole mechanism, and it is worth being precise about the consequence: a liveness probe cannot fix anything. It can only restart. So it is the right tool for a process that has genuinely wedged — a deadlock, a hung event loop — and the wrong tool for anything else. The most common real-world failure is not a sick application but a probe that is too strict for a healthy one: a slow-starting service killed before it finishes booting, or a probe endpoint that checks a downstream dependency and so reports the application dead when the database is merely slow.

Most common causes

• The application is slow to start and has no startupProbe, so the liveness probe kills it mid-boot and it never gets far enough to pass.
• The probe endpoint checks downstream dependencies, so a database problem restarts every replica simultaneously and turns a degradation into an outage.
• timeoutSeconds is set to the default of 1 second, which is not enough for an endpoint that does real work under load.
• The probe targets the wrong port or path — a mismatch between the container port and the probe's port field.
• The application really is deadlocked or has exhausted its thread or connection pool.
• Resource starvation — a CPU-throttled container cannot answer the probe within the timeout even though it is functioning.

How to diagnose it

1. Read the event: kubectl describe pod POD shows Liveness probe failed with the reason, followed by Killing.
2. Distinguish the two shapes of failure. A connection refused means nothing is listening. A timeout means something is listening but did not answer in time. These have different fixes.
3. Check the restart count and its timing: kubectl get pod POD. Restarts at a regular interval matching the probe's period point at the probe, not the application.
4. Try the probe by hand from inside the cluster: kubectl exec POD -- curl -sv localhost:PORT/PATH, if the image has a client.
5. Check whether the container is being CPU-throttled — a container at its CPU limit fails probes that would otherwise pass.

How to fix it

1. For slow starters, add a startupProbe. It suspends the liveness probe until the application is up, which is what inflating initialDelaySeconds is a poor substitute for.
2. Make the liveness endpoint check only the process itself. Dependency health belongs in a readiness probe, where failing removes the pod from the service rather than killing it.
3. Raise timeoutSeconds above 1, and failureThreshold above 1, so a single slow response does not restart a healthy container.
4. Correct the port and path if they do not match what the container serves.
5. Consider removing the liveness probe entirely. A probe that cannot identify a condition a restart would actually fix is providing no value and can only cause harm.

Notes

A liveness probe that checks a shared dependency correlates failures across every replica at once. This turns a partial degradation into a full outage, and it is the single most damaging probe misconfiguration in common use.

Related

• Readiness probe failed — The pod was removed from service endpoints
• Startup probe failed — The container did not finish starting in time

Sources

• Kubernetes documentation — Configure Liveness, Readiness and Startup Probes
• Kubernetes documentation — Pod Lifecycle: container probes
• Kubernetes documentation — Debug Running Pods