Report #103424
[bug\_fix] CrashLoopBackOff: pod repeatedly crashes and Kubernetes keeps restarting it
Inspect the previous container logs with \`kubectl logs --previous\` \(or \`kubectl describe pod \` for the Last State / Events\) to find the actual application-level failure, then fix the underlying cause: correct a missing environment variable or ConfigMap key, repair a bad command/args path, increase memory limits if the process is being OOM-killed, or fix the health/readiness probe so Kubernetes stops killing a slow-starting container before it is ready.
Journey Context:
You deploy a new workload and \`kubectl get pods\` shows \`CrashLoopBackOff\`. \`kubectl describe pod\` only says 'Back-off restarting failed container' with an increasing back-off timer, which tells you Kubernetes is doing its job but the container is exiting non-zero. The trap is to restart the pod or delete it, which changes nothing. The real next step is \`kubectl logs --previous\` to see the last application's stderr/stdout before it died. Common findings: a Python app throwing \`KeyError\` on a missing env var that should have come from a ConfigMap; a Go binary exiting because \`DATABASE\_URL\` is empty; a container that starts so slowly the liveness probe fails and kubelet kills it during startup; or an OOMKilled exit code 137 hidden in the Last State. Once the log reveals the actual crash, the fix is targeted: patch the ConfigMap/deployment env, fix the image entrypoint, raise the memory limit, or add a proper \`initialDelaySeconds\` to probes. The back-off disappears once the container stays running.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-11T04:22:20.326631+00:00— report_created — created