CrashLoopBackOff: Container keeps starting and exiting, so the kubelet is waiting longer between restarts

CrashLoopBackOff means your container started, exited, and was restarted repeatedly, so the kubelet is now delaying each restart. It is a symptom, not a cause — the real error is in the previous container's logs.

Applies to: All Kubernetes versions, any container runtime

What it means

CrashLoopBackOff is not itself a failure. It is the kubelet telling you it has given up restarting your container immediately. When a container in a pod with restartPolicy: Always exits, the kubelet restarts it. If it keeps exiting, the kubelet applies an exponential back-off — 10s, 20s, 40s and so on, capped at 5 minutes — and reports the pod as CrashLoopBackOff while it waits. The back-off resets once the container has run successfully for 10 minutes. The important consequence is that the status tells you nothing about why the container exited. That information is in the logs of the run that already ended, which is why kubectl logs without --previous so often shows nothing useful.

Most common causes

The application exits immediately on startup — a missing environment variable, an unreachable database, a malformed config file.
The container's command finishes successfully and exits. A container that runs a one-shot task under restartPolicy: Always will loop forever; it wants a Job, not a Deployment.
A liveness probe is failing and killing the container before the app finishes starting. This is very common with slow-booting JVM and Rails applications that have no startupProbe.
The process is being OOM-killed on each start, in which case the last state's reason is OOMKilled and exit code 137.
The image entrypoint is wrong — the binary is not at the path given, or the container has no shell and the command assumed one.
A required mounted file or secret is absent, so the app fails its own startup validation.

How to diagnose it

Read the previous container's logs, not the current one: kubectl logs POD --previous. This is the single most useful command for this status and the one most often skipped.
If the pod has several containers, name the one that is failing: kubectl logs POD -c CONTAINER --previous.
Check the exit code and reason: kubectl describe pod POD, then look at Last State. Exit code 137 means it was killed (usually OOM), 143 means it received SIGTERM, 1 or 2 usually means the application itself failed, and 127 means the command was not found.
Look at the Events section of the same output. A liveness probe killing the container appears there as Liveness probe failed followed by Killing.
If the logs are empty, the process is dying before it can log. Override the entrypoint to get a shell and look around: kubectl run debug --rm -it --image=YOUR_IMAGE --command -- sh.

How to fix it

If the logs show an application error, fix the application or its configuration. The status will clear on its own once the container stays up.
If a liveness probe is killing a slow starter, add a startupProbe rather than inflating initialDelaySeconds on the liveness probe. The startup probe suspends the liveness probe until the app is ready, which is what you actually want.
If the container is completing its work and exiting cleanly, change the workload type to a Job or CronJob, or set restartPolicy: OnFailure where the pod spec allows it.
If the exit code is 137, treat it as an OOM problem and raise the memory limit or reduce the application's usage.
If the exit code is 127, the entrypoint path is wrong. Check the image with docker inspect or by running it locally.

Notes

A pod can sit in CrashLoopBackOff for a long time without the back-off ever reaching its 5 minute cap being the problem. Chasing the back-off timing is almost always wasted effort; the exit code is where the answer is.

Sources

Pages on this site are written with AI assistance from the primary sources listed on each page, then checked against those sources before publishing.