LogLens AI / Errors / CrashLoopBackOff

CrashLoopBackOff: how to debug and fix it

TL;DR. CrashLoopBackOff means a Kubernetes pod starts, crashes, and restarts repeatedly, so kubelet adds an increasing back-off delay. It is a symptom — the real error is in the container's logs or its exit code.

What causes CrashLoopBackOff

The app exits on startup (bad config, missing env var or secret, failed dependency connection); it is OOMKilled (exit 137); a failing liveness probe; a bad image command; or a missing file/volume.

How to diagnose it

Run kubectl logs <pod> --previous to see the crashed container's output, and kubectl describe pod <pod> for the exit code and events. Exit 137 = OOM; non-zero app exits point to config or dependency errors.

How to fix CrashLoopBackOff

  1. Read the previous container's logs. kubectl logs <pod> --previous almost always shows the real startup error.
  2. Check the exit code and events. kubectl describe pod — exit 137 means OOM (raise memory); a failing probe means tune livenessProbe timing.
  3. Fix config, then the probe. Supply the missing env/secret/volume or fix the start command; only then adjust restart/probe settings.

Example log line

Last State: Terminated  Reason: Error  Exit Code: 1
Back-off restarting failed container app in pod web-7d9f (reason: CrashLoopBackOff)

How LogLens detects CrashLoopBackOff

LogLens surfaces the crashing container's real error line and groups the restart loop into a single incident. LogLens AI is a free, self-hosted AI log analyzer that surfaces lines like this automatically, groups them into one incident, and explains them in plain language.

Install LogLensSee the tour

Related errors

FAQ

How do I find why a pod is in CrashLoopBackOff?

Run kubectl logs --previous to see the crashed container's output, and kubectl describe pod for the exit code and events.

Does CrashLoopBackOff mean out of memory?

Sometimes — if the exit code is 137 it was OOMKilled. Otherwise it is usually a startup/config error or a failing liveness probe.