Kubernetes CrashLoopBackOff: use the exit reason to find the startup failure
CrashLoopBackOff is a restart state, not the root cause. Previous logs, termination reasons, events, and dependency health reveal what is breaking startup.
Maintained by Kevin · Ovalk
Scope and prerequisites
Kubernetes Pods controlled by a Deployment. StatefulSets and Jobs need controller-specific recovery decisions.
Confirm kubectl context, namespace, Pod and container before running commands. Logs and events need read permissions; rollout changes need separate write access.
Common symptoms
- A Pod remains in CrashLoopBackOff.
- New deployment replicas never become Ready.
- Current logs contain only a fragment of the latest start.
1. Read previous logs and termination state
Use previous-container logs and inspect Last State, exit code, OOMKilled status and Kubernetes events. These have more diagnostic value than a live log stream for a container that immediately exits.
kubectl logs POD_NAME -n NAMESPACE -c CONTAINER_NAME --previous --tail=200
kubectl describe pod POD_NAME -n NAMESPACE2. Match the response to the exit type
OOMKilled points to a memory budget or leak. Exit code 1 often indicates configuration, startup command or dependency failure. Probe failures require comparing real startup time with probe thresholds.
kubectl get pod POD_NAME -n NAMESPACE -o yaml
kubectl top pod POD_NAME -n NAMESPACE --containers3. Compare and roll back deliberately
Diff image, configuration, Secrets, and startup arguments against the last healthy ReplicaSet. When recovery is the priority, roll back while preserving failed pod logs and events for review.
State-changing example below — confirm authorization, scope and recovery before executing.
kubectl rollout history deployment/DEPLOYMENT_NAME -n NAMESPACE
kubectl rollout undo deployment/DEPLOYMENT_NAME -n NAMESPACEInterpret the evidence
| Observation | What to check next |
|---|---|
| OOMKilled | Inspect limits, node pressure and peak memory. Exit code 137 on its own does not identify every cause of SIGKILL. |
| Exit code 0 with repeated restarts | Check whether the image runs a one-off task under a controller expecting a long-running service. |
| No previous logs | Verify the container name and Pod instance. A replacement Pod may not retain the previous Pod's logs. |
Illustrative diagnosis
A hypothetical example to explain the reasoning, not a reported customer incident or a claim of testing on your stack.
A container takes 70 seconds to initialise, but liveness checks repeatedly terminate it at 30 seconds. Previous logs show progress rather than a crash, and events identify probe failures. Measure startup time and configure a startup probe with an appropriate budget; do not hide an actual application exit by making all probes permissive.
Verify recovery
- Confirm desired replicas become Ready and restart counts stop increasing over multiple probe cycles.
- Check real application requests and dependency health. A green Pod alone does not prove the business path recovered.
Rollback and stopping point
A Deployment undo restores an earlier Pod template, not external database changes or edits to a shared ConfigMap/Secret. Confirm compatibility first and retain failed-container evidence before replacing Pods.
Prevention and long-term repair
- Give startup, readiness, and liveness probes distinct purposes.
- Version configuration and run startup smoke tests before rollout.
- Track restart counts, OOMs, and readiness time in release dashboards.
References and corrections
Use the documentation for your installed version. The references below explain the underlying behavior; commands still need environment-specific validation.
Report a correction to Kevin — include the page URL, version and a redacted reproduction. See our editorial policy.