The First Thing I Check When a Pod Is in CrashLoopBackOff. It's Not the Logs.
CrashLoopBackOff is when a pod is in a continuous loop of trying to start and dying. Most likely controlled by a ReplicaSet trying to maintain desired state, or a static pod managed by the kubelet.
Why logs are the wrong first step
When a pod crashes, kubectl logs shows you the application output — but only if the application actually started and produced output. If it crashed before producing anything, logs are empty and useless.
The exit code tells you why the process died at the OS level, before the app even had a chance to log anything.
What the exit codes mean
| Exit code | Meaning |
|---|---|
| 0 | Process exited cleanly, no error. Usually a misconfigured command that completes and exits instead of running continuously. |
| 1 | Application error. Something in your code crashed. Now you go check logs. |
| 137 | OOMKilled. Container exceeded its memory limit and the kernel killed it. Logs won't tell you this as clearly or as fast. |
| 139 | Segfault. Something in the binary crashed at the C level — common with native dependencies built for the wrong architecture. |
| 143 | Container received SIGTERM and didn't shut down in time. Usually missing graceful-shutdown handling. |
My debugging order
kubectl describe pod <pod-name>— check the Events section and the exit code underLast State- The exit code tells me the category of failure
- Then I decide whether logs are even worth checking
Faster than scrolling logs that might not exist:
kubectl describe pod <pod-name> | grep -A 5 "Last State"That snippet gets you the exit code in 2 seconds. From there, the table above tells you whether to check logs (1, 139), check resource limits (137), or check your container CMD (0).
CrashLoopBackOff is one of the most common errors you'll face in Kubernetes. How do you handle it when you see it?
Originally shared on LinkedIn.