Kubernetes "CrashLoopBackOff" after a CI deploy - Fix it

CrashLoopBackOff is a symptom: the container started, exited, and the kubelet restarted it, backing off (10s, 20s, 40s ... up to 5m) after repeated fast exits. The image is fine; the process is dying at boot. The cause is in the logs and the exit code.

What this error means

A kubectl rollout status in CI never reaches Ready, and kubectl get pods shows CrashLoopBackOff with a climbing restart count.

NAME                  READY   STATUS             RESTARTS      AGE
api-7c9d8f6b5-2xqzr   0/1     CrashLoopBackOff   5 (38s ago)   3m12s

Common causes

The process exits at startup

A missing env var, a failed dependency connection at boot, a bad config, or an unhandled exception kills the process within seconds.

A wrong command, entrypoint, or one-shot script

The image command points at a missing binary, or runs a script that completes and exits, which Kubernetes treats as a crash for a long-running pod.

How to fix it

Read the previous container logs

The live container may be too young to have logs; --previous shows the last crashed instance with the real stack trace.

kubectl logs deploy/api --previous
kubectl describe pod <pod>   # Last State / Exit Code / Reason

Map the exit code and fix the boot failure

1. Read the exit code: 1 = app error (read logs), 137 = OOMKilled/SIGKILL, 139 = segfault, 143 = SIGTERM.
2. Supply the missing env/secret/config the logs name, or fix the command/args.
3. Re-apply and watch rollout status to Ready.

How to prevent it

• Validate required env/secrets at startup with a clear fatal message.
• Run the image locally with prod-like config before shipping it.
• Add a readiness gate so a crashing rollout fails fast.

Related guides