CrashLoopBackOff is not an error of its own. It is the kubelet telling you that a container keeps exiting, and that it is waiting longer before each restart: ten seconds, then twenty, forty, and so on up to five minutes. The cause is always in the container’s last exit, and four commands find it.
1. Which pod, and how often
kubectl get pods -n shop
The RESTARTS column says how many times the container has been restarted, and STATUS shows CrashLoopBackOff while it waits for the next attempt. A pod that shows Running with a climbing restart count has the same problem; you just looked between crashes.
2. How the last run ended
kubectl describe pod checkout-5c8d7-q2v9n -n shop
Look at Last State under the container: Terminated, with a Reason and an Exit Code. Those two lines narrow the search more than anything else:
| Exit code | Usually means |
|---|---|
0 | The process finished. A Deployment’s container is expected to keep running, so a command that completes is restarted forever. Check the command and arguments. |
1 | The application failed on its own: a missing setting, a refused connection, an exception at start. The logs say which. |
126 / 127 | The command is not executable, or not found in the image. Check the entrypoint and the image tag. |
137 | Killed with SIGKILL. With the reason OOMKilled, it ran out of its memory limit; without it, something killed it, often after a failed liveness probe. |
139 | A segmentation fault inside the process. |
143 | Stopped with SIGTERM, which is what a failing liveness probe does first. |
The Events at the bottom of the same output show probe failures (Liveness probe failed), image pull problems and back-off restarts in order.
3. What it printed before it died
kubectl logs checkout-5c8d7-q2v9n -n shop --previous
--previous reads the container instance that crashed, not the one waiting to start. Add -c <container> when the pod has more than one. A line like exec format error means the image was built for another CPU architecture than the node’s.
4. What changed
kubectl rollout history deployment/checkout -n shop kubectl get events -n shop --sort-by=.lastTimestamp
A crash loop that starts right after a rollout is almost always the rollout: a new image, a new environment variable, a lower memory limit. If the previous revision worked, going back is one command, and you can look for the cause with production healthy again:
kubectl rollout undo deployment/checkout -n shop
The usual causes
- Configuration. A variable, secret or config file the new version reads and the cluster does not have.
- Memory.
OOMKilled: raise the limit, or find what grew. A cache sized for a bigger machine is a common one. - Probes. A liveness probe that starts checking before the application is ready kills it every time. Give slow starters a
startupProbe, or a longerinitialDelaySeconds. - Dependencies. A process that exits when its database is not reachable at start will loop until the database is. Retrying on start, or failing readiness rather than exiting, keeps the pod alive.
- The image. A wrong tag, a missing entrypoint, or the wrong architecture.
Doing the same with Runa
In Subnomic the cluster’s agent dials out, and kubectl works through a generated kubeconfig, so every command above runs as it is. Runa, Subnomic’s assistant, can do the reading for you through an agent access that can read the cluster:
crashloop_reportlists the pods in a namespace that are restarting, OOM-killed or not running, each with its restart count and its last exit code and reason.investigate_resourcepulls one pod’s status, events, restart and OOM signals and recent logs into a single report.kube_events,kube_logsandrollout_historydo what their kubectl counterparts do;recent_changessearches the activity log for deploys, scales and restarts near the start.
Each call is shown with its arguments, so you can check the reading. A fix is a separate step: restarting, scaling or setting an image needs an access that may change workloads, and a guardrail that requires approval stops it. A whole walkthrough is in Investigate a Kubernetes incident with an AI agent; the cluster setup is in Kubernetes.