Kubernetes "CrashLoopBackOff" after deploy in CI - Fix it

By Daniel Zoghalchali·Latchkey

CrashLoopBackOff is not the error - it is the symptom. Your container started, exited (cleanly or with a crash), and the kubelet restarted it; after repeated fast exits it backs off (10s, 20s, 40s ... up to 5m). The real failure is in the container logs.

What this error means

A kubectl rollout status or kubectl get pods in CI shows the pod stuck in CrashLoopBackOff with a climbing restart count. The deploy step never reaches Ready and the pipeline times out or fails the rollout.

kubectl

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

Common causes

The process exits immediately

A missing env var, a failed DB connection at boot, a bad config file, or an unhandled exception kills the process within seconds of start. The kubelet restarts it and the cycle repeats.

Wrong command or entrypoint

The image command/args point at a binary that is not there, or the entrypoint runs a one-shot script that completes and exits, which Kubernetes treats as a crash for a long-running pod.

How to fix it

Read the crashing container logs (including the previous attempt)

The live container may be too young to have logs; --previous shows the last crashed instance, which is where the real stack trace lives.

Terminal

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

Fix the boot failure, then redeploy

Map the exit code: 1 = generic app error (read logs), 137 = OOMKilled/SIGKILL, 139 = segfault, 143 = SIGTERM.
Supply the missing env var, secret, or config the logs name, or correct the image command/args.
Re-apply and watch kubectl rollout status until the pod is Ready.

How to prevent it

Add a readiness gate so a crashing rollout fails the deploy fast instead of churning.
Validate required env/secrets at startup with a clear fatal message, not a stack trace.
Run the image locally (docker run) with prod-like config before shipping to the cluster.

Frequently asked questions

What causes ""CrashLoopBackOff""?

A missing env var, a failed DB connection at boot, a bad config file, or an unhandled exception kills the process within seconds of start. The kubelet restarts it and the cycle repeats.

How do I fix "CrashLoopBackOff"?

The live container may be too young to have logs; --previous shows the last crashed instance, which is where the real stack trace lives.