CrashLoopBackOff is not an error by itself. It is Kubernetes telling you that a container starts, exits, gets restarted and exits again, so the kubelet is waiting longer and longer between restarts. Your job is to find out why the container exits.

Step 1: Look at the pod

bash
kubectl get pods
kubectl describe pod <pod-name>

In describe, check:

  • Last State – the exit code and reason (Error, OOMKilled, Completed).
  • Events – failed probes, image problems, mount errors.

Step 2: Read the logs of the crashed container

The current container may not have logged anything yet. Get the previous one:

bash
kubectl logs <pod-name> --previous
kubectl logs <pod-name> -c <container-name> --previous   # multi-container pods

Step 3: Interpret the exit code

  • Exit code 1 – the application raised an error. The logs usually say which.
  • Exit code 137 – the container was killed, most often OOMKilled (out of memory).
  • Exit code 139 – segmentation fault in native code.
  • Exit code 0 with restarts – the process finished. A container must keep running; a job that exits belongs in a Job, not a Deployment.

The most common causes and fixes

Missing configuration

The app fails because an environment variable, secret or config file is missing. Fix: check env, envFrom and mounted secrets in the manifest; confirm the Secret or ConfigMap exists in the same namespace.

Cannot reach a dependency

The app exits because the database or another service is unreachable at startup. Fix: verify the service name and port, check network policies and add retry logic instead of exiting on the first failure.

Out of memory

Exit code 137 with reason OOMKilled. Fix: raise the memory limit to match real usage, or fix the leak. For JVM and Node apps, make sure heap settings respect the container limit.

yaml
resources:
  requests: { memory: "256Mi", cpu: "100m" }
  limits:   { memory: "512Mi" }

Liveness probe kills a healthy app

A liveness probe that runs before the app is ready, or times out under load, restarts a working container. Fix: add a startupProbe for slow starts, and make liveness checks cheap and independent of external dependencies.

Wrong command or entrypoint

A typo in command/args, or an image built for a different CPU architecture (exec format error). Fix: run the image locally with the same command, and build multi-architecture images when needed.

File permissions

The container runs as a non-root user but writes to a path it does not own. Fix: set correct ownership in the Dockerfile or use securityContext.fsGroup.

Debug interactively

Attach an ephemeral debug container that shares the crashing container's process namespace:

bash
kubectl debug -it <pod-name> --image=busybox --target=<container-name>

Key takeaways

  • CrashLoopBackOff means the container keeps exiting; find out why.
  • Start with kubectl describe and kubectl logs --previous.
  • Exit code 137 usually means out of memory.
  • Missing config, unreachable dependencies and aggressive probes are the top causes.