How to Fix Kubernetes CrashLoopBackOff
CrashLoopBackOff means your container starts, exits, and Kubernetes keeps restarting it with growing back-off delays. It's a symptom, not a cause - here's how to find the real reason and fix it.
What CrashLoopBackOff means
Kubernetes started your container, it exited (crash or non-zero exit), and Kubernetes restarted it - over and over, waiting longer between tries (the "back-off"). The status tells you the pod can't stay up; it doesn't tell you why. Your job is to find the exit reason.
Step 1: look at the pod
kubectl get pods
kubectl describe pod <pod> # Events + last state + exit code
In describe, check Last State -> Terminated for the exit code and Reason,
and read the Events at the bottom.
Step 2: read the logs (including the crashed run)
kubectl logs <pod> # current attempt
kubectl logs <pod> --previous # the run that just crashed - this is the gold
--previous shows the output of the container that already died, which usually contains
the actual error (stack trace, "command not found", "missing env var", etc.).
The common causes (and the fix)
- Bad command / typo in args - e.g.
sleeepinstead ofsleep. The container exits instantly. Fix the command in the Deployment and re-apply. - Missing config/secret/env var - the app throws on startup. Add the ConfigMap/Secret or the env var it expects.
- Failing liveness probe - the probe kills a container that's actually fine but slow to
start. Add a
startupProbeor raiseinitialDelaySeconds. - OOMKilled (exit
137) - the container exceeds its memory limit. Raiseresources.limits.memoryor fix the leak. - Image/dependency error - a missing file or unreachable dependency at boot.
Step 3: apply the fix and watch the rollout
kubectl apply -f deployment.yaml
kubectl rollout status deployment/web --timeout=90s
A clean rollout status means the pod is now staying up.
The mental model
CrashLoopBackOff is always "the container exited - find out why." describe for the exit
code + events, logs --previous for the error, then fix the command, config, probe, or
memory that caused the exit.
Want to try it hands-on? HeyDevJob gives you this exact setup in a live cloud workspace in your browser - edit it, run it, and see it work. Free, nothing to install.
Try it in a workspace →What you'll practice
- Reading kubectl describe for the exit code + events
- Using kubectl logs --previous to see the crashed run's error
- Fixing the root cause and confirming with kubectl rollout status
FAQ
What does CrashLoopBackOff mean in Kubernetes?
CrashLoopBackOff means a pod's container starts, crashes, and Kubernetes keeps restarting it - waiting longer between each attempt (the "back-off"). Kubernetes isn't the problem; the container itself is exiting right after it starts.
What is the reason for CrashLoopBackOff?
The container exits immediately after starting - commonly a bad command or typo, a missing config or env var, a failing liveness probe, running out of memory (OOMKilled, exit 137), or a missing file/dependency at boot.
How do I debug a pod stuck in CrashLoopBackOff?
Run kubectl describe pod <pod> for the exit code and events, then kubectl logs <pod> --previous to see the output of the run that just crashed - that almost always contains the real error. Exit 137 means OOMKilled (raise the memory limit); a non-zero app exit means read the logs.
What is the CrashLoopBackOff limit in Kubernetes?
There is no restart-count cap - Kubernetes keeps trying. The "limit" is the back-off delay between restarts, which grows exponentially (10s, 20s, 40s ...) and is capped at 5 minutes (300s) until the container stays up.
Keep learning
Learn it by doing. Open this in a live cloud workspace, make the change yourself, and keep a record of the work you can share.
Open the workspace →