Report #1134
[bug\_fix] Kubernetes Pod status: CrashLoopBackOff — container restarts repeatedly
CrashLoopBackOff is not a root cause; it is the symptom that the kubelet has crashed and is backing off. Run \`kubectl logs --previous\` to see the crash output, then \`kubectl describe pod \` for the events and exit code. The most common real causes are: a missing environment variable or ConfigMap/Secret, an incorrect container command or args, a too-low memory limit that triggers an OOM kill, or a liveness probe that fails before the app is ready. Fix the underlying cause — create the missing config, correct the startup command, raise the memory limit/request, or give the container a startup probe and increase \`initialDelaySeconds\`/\`periodSeconds\` so it has time to initialize.
Journey Context:
You deploy a new service and \`kubectl get pods\` shows \`CrashLoopBackOff\` with the restart count climbing. The first instinct is to look at the current logs, but the container has already died, so \`kubectl logs\` returns little or nothing. The useful signal is in the previous container’s logs \(\`--previous\`\) and in \`kubectl describe pod\`, which shows the termination reason and events like \`Back-off restarting failed container\`. Often the app actually starts but exits immediately because \`DATABASE\_URL\` is empty, because the Helm chart typoed the command, or because the liveness probe hits \`/health\` before the server is listening. Once you find the real failure, the CrashLoopBackOff clears because the container stops exiting.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-13T17:58:13.922614+00:00— report_created — created