You type kubectl get pods just before lunch and one line says CrashLoopBackOff, with a restart count that keeps going up every time you look. The app worked yesterday. Nothing in the word itself tells you why it stopped.

Fact-checked against the official sources on 30 October 2026.

A pod is the smallest thing Kubernetes runs: one or more containers that live together. CrashLoopBackOff means a container in the pod keeps starting, crashing, and being restarted, and Kubernetes is now waiting longer between each restart. By default the wait goes 10 seconds, 20, 40 and so on, up to 5 minutes. If the container then runs fine for 10 minutes, the timer resets.

One detail saves confusion: CrashLoopBackOff is a status that kubectl shows you, not one of the official pod phases. It's a symptom. Two commands get you to the cause.

Read the describe output first

Run this, swapping in your own pod name for the made-up tide-tables-api-4k2mp we'll use throughout:

kubectl describe pod tide-tables-api-4k2mp

Scroll to the container section. The Kubernetes debugging page shows these fields in its own crashing-container example:

  1. State: what the container is doing now. In a crash loop this is usually Waiting with reason CrashLoopBackOff.
  2. Last State: what happened the last time it ran. Start here, and look at its Reason and Exit Code (the number a program returns when it stops; 0 means it ended normally, anything else means something went wrong).
  3. Restart Count: how many times it has been restarted.
  4. Events: at the bottom. These are short notes from Kubernetes, like an image that couldn't be pulled or a health check that failed.

Then read the logs from the crash

Plain kubectl logs shows the container that's running now, which may have just started and printed nothing. To see what the crashed one said before it died, add --previous:

kubectl logs tide-tables-api-4k2mp -c api --previous

The -c api part names the container (here, one called api). You can leave it out when the pod has only one.

Walk through a small example

Here's part of the describe output for that made-up "tide-tables" pod:

State: Waiting Reason: CrashLoopBackOff Last State: Terminated Reason: Error Exit Code: 1 Restart Count: 6

Exit code 1 with reason Error says the app itself quit. So you check the logs from the crash:

kubectl logs tide-tables-api-4k2mp --previous 
config error: TIDE_DATA_URL is not set

Now you know. A recent change dropped an environment variable. Put it back, redeploy, and the restart count stops climbing.

Match what you see to a likely cause

The pod lifecycle page lists the usual suspects. Use what you found to pick one:

  1. The app crashes on start: the logs show an error or stack trace. Fix the code or its input.
  2. Config is wrong: a missing environment variable or config file, like the example above.
  3. Resource limits: it runs out of memory (Last State reason: OOMKilled) or gets too little CPU to start before its probes give up. The two limits behave differently: going over the memory limit can get the container killed, while a CPU limit only slows it down (throttling). A slow start turns into a restart only when a probe runs out of patience.
  4. A health check fails: when a startup or liveness probe keeps failing, the kubelet (the node's local Kubernetes agent) kills the container, then starts a fresh one. The Events section will show it.

Why production teams notice this

Kubernetes is one of the tools in DevGrid Staffing LLC's DevOps and cloud engineering work, next to our IT staffing. Reading describe and --previous calmly, before changing anything, is a habit production teams notice quickly.

One thing to try today

Pick any pod in a test cluster that has restarted at least once. Run kubectl describe pod on it and find the Last State reason and exit code.

From the DevGrid Staffing LLC notebook · devgridstaffing.com