How to fix CrashLoopBackOff in Kubernetes
CrashLoopBackOff is not the error: it is Kubernetes telling you the container starts, dies and is restarted, with a growing wait between attempts, up to 5 minutes. The cause is in what the container did before it died. These are the steps to find it.
1. Find the pods in CrashLoopBackOff
The RESTARTS column shows how many times the container has restarted:
kubectl get pods -A | grep -E "CrashLoopBackOff|Error"2. Read the log of the run that died
The current log may be empty because the container has just restarted. --previous shows the log of the previous run, the one that failed:
kubectl logs <pod> -n <namespace> --previous
kubectl logs <pod> -n <namespace> -c <container> --previous3. Read the exit code and the events
Under Last State, describe shows the Reason and the Exit Code of the last termination. At the end, the events show probe and volume mount failures:
kubectl describe pod <pod> -n <namespace>What the exit code tells you
- Exit Code 1 or another application code: the app exited with an error. The cause is in the --previous log: a missing environment variable, invalid configuration, a database or queue down at startup.
- Exit Code 137 with Reason OOMKilled: the container went over its memory limit.
- Exit Code 137 without OOMKilled: the process got SIGKILL, usually because the liveness probe failed and the kubelet killed the container.
- Exit Code 0: the process ended without error, but the Deployment expects a process that keeps running. Common with an image whose command runs and exits.
- Exit Code 126 or 127: the container command is not executable or does not exist (wrong command and args).
Common causes
- Aggressive liveness probe: initialDelaySeconds or timeoutSeconds too short for an app that is slow to start. Use a startupProbe to cover startup time.
- A ConfigMap or Secret with a wrong value, or a variable the app requires that is not in the pod.
- A dependency down at startup (database, queue, another service) and the app exits instead of retrying.
- Permissions: the image needs to run as root, or to write to a directory the securityContext made read-only.
Without a terminal, in Kubepier
In Kubepier, each pod’s status shows the reason (CrashLoopBackOff, OOMKilled, Error), and failing pods and warning events rise to the top, from any cluster, in the browser or on your phone. On Pro, live logs and the shell open right there, and on the desktop the AI diagnosis explains the CrashLoopBackOff from the events and the log.