How do you fix CrashLoopBackOff in Kubernetes?

Quick answer: CrashLoopBackOff means the kubelet is repeatedly starting a container, watching it exit, and waiting an increasing back-off period before trying again — it is a status, not a root cause. Kubernetes actually reports the underlying event as "Back-off restarting failed container," which is the exact phrase worth searching your cluster events for. Fixing it means finding out why the container keeps exiting, not just restarting the pod.

What the status actually means

A pod in CrashLoopBackOff has a container that started, then exited (either with an error or was killed), and the kubelet is retrying it with exponential back-off (10s, 20s, 40s... capped at 5 minutes) rather than restarting it in a tight loop. The back-off itself is not the problem — it is Kubernetes correctly refusing to hammer a container that keeps failing. The problem is whatever is making the container exit in the first place.

Debugging checklist

1. `kubectl describe pod <pod-name>` — check the Events section at the bottom first. This is where you will see "Back-off restarting failed container" plus, often, the real clue right above it (an OOMKilled reason, a failed probe, an image pull error).
2. `kubectl logs <pod-name> --previous` — the --previous flag is essential: the current container instance may not have logged anything yet, but the previous crashed instance almost always has the actual error (stack trace, missing env var, connection refused).
3. Check the exit code — kubectl describe pod shows Last State: Terminated, Reason, Exit Code. Exit code 1 is a generic app error (check logs); exit code 137 means the container was killed, usually OOMKilled (check describe pod for OOMKilled and the container's memory limit).
4. Bad command or entrypoint — a Dockerfile CMD/ENTRYPOINT or a pod spec command/args that references a binary or script that does not exist in the image exits immediately on every attempt; this is one of the most common causes for a brand-new deployment.
5. Missing ConfigMap, Secret, or environment variable — an app that hard-fails on startup when a required config value or secret is absent will crash-loop the moment the container starts; check kubectl describe pod for CreateContainerConfigError alongside the loop, which flags this specifically.
6. Failing readiness/liveness probe — a liveness probe that fails repeatedly gets Kubernetes to kill and restart the container itself, which looks identical to an app crash from the outside; check the probe's path/port/timeout against what the app actually exposes and how long it takes to become ready.
7. OOMKilled — the container is being killed for exceeding its memory limit; either the limit is set too low for the app's real usage or there is a genuine memory leak. Compare kubectl top pod usage against the configured resources.limits.memory.
8. App crashes on startup for an app-level reason — a database connection it cannot make yet, a migration that has not run, a dependency that is not reachable. --previous logs are the way to see this.

This pairs with the wider question of how you achieve zero-downtime deployments in Kubernetes — a rollout that introduces a crash-looping pod is exactly the failure mode a proper readiness gate and rollout strategy is meant to catch before it reaches all replicas.

If you are stuck on a specific crash loop and want a second pair of eyes, that is exactly what an office-hours call is for.