How to Debug and Fix CrashLoopBackOff Pods in Kubernetes
A `CrashLoopBackOff` indicates that a container started, crashed, and Kubernetes is waiting through exponential backoff before restarting it. The root cause is almost always an unhandled application exception, missing environment variable, failed DB migration, or out-of-memory (OOM) termination.
kubectl logs my-app -n default --previous && kubectl describe pod my-app -n defaultFlags & Parameter Breakdown
--previousFetch logs from the crashed container instance before the restart-c <container>Specify container name if multiple exist in podStep-by-Step Execution Workflow
Fetch the stdout/stderr log output from the container immediately before it died:
kubectl logs my-pod -n default --previousLook at the "Last State" section to find the Exit Code and termination reason:
kubectl describe pod my-pod -n defaultExit Code 137 indicates the container exceeded its memory limit and was killed by the Linux kernel OOM killer.
Common Pitfalls & Troubleshooting Advice
- Exit Code 137: Pod was killed due to Out Of Memory (OOM). Increase `resources.limits.memory`.
- Exit Code 1: Application threw an uncaught error (e.g. missing DB connection string or secrets).
- Exit Code 143: Graceful SIGTERM received (usually pod eviction or liveness probe failure).
- Check if livenessProbe `initialDelaySeconds` is too low, causing Kubelet to kill the app before it finishes booting.
Prerequisites & Cluster Access
- kubectl access with describe and logs permissions.
Frequently Asked Questions About Debug CrashLoopBackOff
Frequently Asked Questions
Everything you need to know regarding specifications, syntax, and security best practices.
It means the pod repeatedly exits with an error status, and Kubelet delays successive restarts by 10s, 20s, 40s, up to 5 minutes to avoid burning CPU cycles.