Report #101469
[bug\_fix] CrashLoopBackOff
Run \`kubectl describe pod\` to confirm the crash reason, then \`kubectl logs --previous\` \(or \`kubectl debug\` for distroless images\) to read the previous container's crash output. Fix the underlying application failure—commonly a missing required environment variable, bad config file path, unhandled exception on startup, or a dependency that is unreachable—and redeploy. The pod will stop cycling once the container process stays alive.
Journey Context:
We had just pushed a new Python FastAPI service to an EKS 1.29 cluster. The Deployment rolled out, but \`kubectl get pods\` showed every replica stuck in \`CrashLoopBackOff\` with rapidly climbing restart counts. \`kubectl describe pod\` reported \`State: Waiting\` with \`Reason: CrashLoopBackOff\` and \`Last State: Terminated\` with \`Exit Code: 1\`, which told us the container was starting and then immediately exiting. \`kubectl logs\` showed nothing because the current container had not stayed up long enough to emit logs, so we used \`kubectl logs --previous\` and saw a traceback ending in \`KeyError: 'DATABASE\_URL'\`. The image expected \`DATABASE\_URL\` to be injected from a Secret, but the manifest referenced the wrong secret name. We fixed the env var source, applied the manifest, and the new pods came up \`Running\` and stayed there. The reason this works is that CrashLoopBackOff is only a symptom—the kubelet is restarting a container whose main process keeps terminating; once the root cause that makes the process exit is removed, the restart loop ends.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-07T04:54:29.021109+00:00— report_created — created