CrashLoopBackOff

Pod restart loop diagnosis, previous logs, init containers, liveness probes, resource limits, and config errors.

Overview

Overview

CrashLoopBackOff is a Kubernetes status meaning a container keeps crashing and Kubernetes waits longer before each restart. The backoff starts at 10 seconds and doubles (20s, 40s, 80s... up to 5 minutes). The status is not the error itself: the repeated crashing is.

Why containers crash

  • Application error — Panic, exception, non-zero exit code
  • OOM kill — Container exceeded its memory limit
  • Liveness probe failure — Probe configured with too aggressive thresholds
  • Missing configuration — Environment variable or config file not found
  • Dependency not available — A service it requires is not running
  • Permission errors — Running as non-root but needing root for file access

Commands and what each tells you

  • kubectl logs --previous — Logs of the last terminated container, where the crash reason usually is: a stack trace, "file not found", "connection refused to database"
  • kubectl logs without --previous — The current restarting container, which may show nothing yet
  • kubectl describe pod — Exit code, restart count, and events at the bottom: image pull failures, volume mount failures, OOM events
  • kubectl logs -c — Init container logs

> [!IMPORTANT] Always add --previous: the crash reason lives in the last terminated container's logs.

Exit codes

  • 1 — General error
  • 137 — OOM killed, SIGKILL
  • 143 — SIGTERM
  • 2 — Misuse of shell command

Init containers

Init containers run to completion before the main container starts. If an init container is crashing, the main container never starts.

> [!TIP] When the main container shows no logs at all, check the init containers first.

Key concepts

kubectl logs --previous
Shows logs from the last terminated container instance. Essential for CrashLoopBackOff — the current container may have just started and shows no logs yet.
Exit code 137
Container received SIGKILL — either OOM killed (memory limit exceeded) or forcibly terminated. Check kubectl describe pod for "OOMKilled" in Last State.
Exit code 1
General application error. Check --previous logs for the exception, panic, or error message that caused the crash.
Liveness probe
Kubernetes periodically checks if the container is alive. If it fails consecutively (failureThreshold times), the container is restarted. Misconfigured probes (too short initialDelaySeconds) cause CrashLoopBackOff on slow-starting apps.
Init container
Runs and must complete successfully before the main container starts. Used for setup tasks (schema migration, config generation). If init container crashes, the main container never starts.

When to use it

  • Diagnosing why a newly deployed pod is not coming up
  • Distinguishing between an OOM kill (137), app crash (1), and liveness probe failure
  • Debugging an init container that is blocking main container startup
  • Finding the configuration error causing a pod to crash on startup

Interview questions

  • A pod is in CrashLoopBackOff. Walk through your complete diagnosis.

Sign up free to read the full topic

More Troubleshooting topics

Start free on Cariara · Coding problems · System design studio