CrashLoopBackOff is not the error — it is Kubernetes giving up on restarting a container that keeps dying. The real error is in the previous container's logs.
Bad env var, missing secret, unreachable dependency, or a config syntax error. The process exits 1 immediately.
Probe kills the container before the app finishes booting — classic for JVM and Rails apps with slow warmup.
Container exceeds its memory limit and gets SIGKILLed. Last State in describe shows Reason: OOMKilled.
kubectl logs <pod> --previous --tail=100
kubectl describe pod <pod> | grep -A6 'Last State'
startupProbe:
httpGet: { path: /healthz, port: 8080 }
failureThreshold: 30
periodSeconds: 5
kubectl rollout restart deployment/<name>
A pattern of exit code 1 within a second of start is almost always config. A container that runs fine for minutes then dies points at memory or a runtime crash — pull the previous logs before changing anything.
A restartPolicy of Always (the default) makes the kubelet retry failed containers with exponential backoff — CrashLoopBackOff is the backoff state, not a separate error. The real failure is in the container logs of the previous attempt.
kubectl logs <pod> --previous shows the last crashed attempt — the one whose exit started the backoff. Without --previous you may catch the current attempt before it dies, or nothing at all.
Kustomize base with probes, PDBs, and zero-downtime rollouts already wired.
Kubernetes Production Blueprints — $27 →One-time. Yours to modify. Instant download from the NinjaOps template store.