Kubernetes Error
Kubernetes Error: CrashLoopBackOff
A container in the pod is starting, crashing, and being restarted repeatedly, with Kubernetes applying an increasing delay between attempts.
What This Error Means
CrashLoopBackOff means Kubernetes successfully started the container, but it exited (crashed, or completed and wasn't supposed to) shortly after — repeatedly. "BackOff" refers to Kubernetes progressively increasing the delay between restart attempts (10s, 20s, 40s...) to avoid hammering resources on a container that keeps failing.
Why It Occurs
The application inside the container is crashing on startup due to a bug, a missing configuration/environment variable, a failed dependency connection (database not reachable), or the container's main process is exiting immediately for a reason unrelated to a true "crash" (e.g. its entrypoint command finished and exited 0, which Kubernetes still treats as needing a restart in a Deployment).
Symptoms
- ⚠ `kubectl get pods` shows the pod status as CrashLoopBackOff
- ⚠ Restart count climbs steadily over time
- ⚠ The pod never reaches Running state or reaches it only briefly
Common Causes
- • Application error/exception on startup
- • Missing or incorrect environment variables/ConfigMap/Secret values the app needs to start
- • A required dependency (database, another service) is unreachable, and the app doesn't retry gracefully
- • Insufficient memory causing an OOM kill immediately after start
- • The container's command/entrypoint is misconfigured and exits immediately
How to Fix It
- Check the previous container's logs (the current crashed instance): `kubectl logs pod-name --previous` — this shows the actual error that caused the crash, which is almost always the fastest path to the real cause
- Check pod events for more context: `kubectl describe pod pod-name` — look at the Events section near the bottom for OOMKilled, failed liveness probes, or other Kubernetes-level context
- Verify environment variables and mounted ConfigMaps/Secrets are correct: `kubectl exec` into a similar working pod, or check `kubectl describe pod` for what's actually mounted
- If OOMKilled appears in `kubectl describe pod`, increase the container's memory limit in the pod spec
- If a dependency (database, API) is unreachable, verify network policies, service DNS names, and that the dependency is actually running and reachable from within the cluster
| Command | Purpose |
|---|---|
| kubectl logs pod-name --previous | View logs from the crashed container instance, not the new restarting one |
| kubectl describe pod pod-name | See pod events, including OOMKilled or failed probes |
Verification
- ✓ `kubectl get pods` shows the pod reaching and staying in Running state
- ✓ Restart count stops climbing
Prevention
- → Set appropriate memory/CPU requests and limits based on actual measured usage, not guesses
- → Implement retry logic with backoff in the application for dependency connections instead of crashing immediately
- → Use readiness/liveness probes correctly configured so Kubernetes doesn't restart a genuinely-still-starting container prematurely