Kubernetes CrashLoopBackOff: a step-by-step diagnosis

CrashLoopBackOff is not an error in itself — it means a container keeps exiting and kubelet is backing off. Find the exit code, read the previous logs, and fix the cause.

What the status means

The container started, exited, and was restarted — repeatedly. Kubelet waits longer each time (10s, 20s, 40s… up to 5 minutes). The real error is whatever made the process exit.

1. Get the exit code

kubectl describe pod <pod> -n <ns>

Under Last State, note Reason and Exit Code.

Exit code	Usual meaning
1	Application error — read the logs
126 / 127	Command not executable / not found
137	Killed (`OOMKilled` or failed liveness probe)
139	Segmentation fault
143	SIGTERM — graceful shutdown that never finished

2. Read the logs from the crashed run

kubectl logs <pod> -n <ns> --previous

--previous matters: the current container may have only just started.

3. Fix by cause

OOMKilled (137): raise the memory limit or fix the leak.

resources:
  requests:
    memory: "256Mi"
  limits:
    memory: "512Mi"

Liveness probe kills a slow starter: add a startup probe instead of a longer initialDelaySeconds.

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 5

Missing config or secret: check kubectl get events -n <ns> --sort-by=.lastTimestamp for CreateContainerConfigError or mount failures.

4. Debug interactively

kubectl debug -it <pod> -n <ns> --image=busybox --target=<container>

Verify

kubectl get pod <pod> -w should show Running with RESTARTS no longer increasing.