CrashLoopBackOff: Find the Cause in Three Commands

What the loop actually is

Kubernetes keeps a container running by starting it again whenever it stops. If it stops again soon after starting, Kubernetes backs off: it waits a little longer before each new start, and shows CrashLoopBackOff while it waits. That is why the status can look like ordinary waiting while nothing works.

One turn of the loop

1. Container starts. Your process begins, reads its config, connects to things.

1 / 5

The three commands

bash

kubectl logs POD --previous
kubectl describe pod POD | grep -A3 'Last State'
kubectl describe pod POD

--previous matters. Once the container has restarted, plain kubectl logs shows the new run, which has probably not failed yet.
Last State gives the reason and exit code of the run that died.
The events at the end of describe show probe failures and missing objects.

What they usually say

A stack trace or fatal error: the application exits on startup. A missing environment variable, a database it cannot reach at boot, a config file in the wrong place. The container is telling you exactly what is missing.
Reason: OOMKilled, Exit Code: 137: it ran out of memory. That has its own page.
Liveness probe failed in events: often Kubernetes is killing a healthy process that simply boots slower than the probe allows. Use a startup probe for slow starters. A liveness probe is the regular health check that restarts a container when it fails; a startup probe holds it off until the app is up.
No output and exit code 0: the command finished. A one-shot script in a Deployment is restarted forever, even though it worked.

The full checklist, with every cause and its confirming command, is on the CrashLoopBackOff page. If the pod never starts at all, look at CreateContainerConfigError instead.