What you'll see
The pod never reaches Running for long, and the restart count climbs:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
api-7d9f8c6b4-x2k9p 0/1 CrashLoopBackOff 6 4m"BackOff" just means Kubernetes is waiting longer between each restart (10s, 20s, 40s… up to 5 min). It's a symptom — the real failure is whatever makes the container exit. Your job is to read why it exited.
Why a container crash-loops
The app exits non-zero on startup
A missing env var, an unreachable database, or an unhandled exception kills the process the moment it boots.
A liveness probe is failing
If the app is slow to start, the liveness probe trips and Kubernetes kills a perfectly healthy container before it's ready.
OOMKilled — out of memory
The container exceeded its memory limit and was killed. You'll see Reason: OOMKilled and exit code 137 in describe.
Missing config or secret
A referenced ConfigMap/Secret key doesn't exist, or a mounted file the app expects isn't there, so it aborts immediately.
Diagnose it in three steps
Read the logs of the crashed instance
The current container may be too new to have logs — use --previous to see the one that just died:
kubectl logs <pod> --previous
kubectl logs <pod> --previous --tail=50Check the exit code and events
kubectl describe pod <pod>
# Look at: Last State, Reason, Exit Code, and the Events list.
# 137 = OOMKilled or SIGKILL. 1/2 = app error. 127 = command not found.Reproduce without the loop
Override the entrypoint so the container stays up and you can poke around:
kubectl run debug --rm -it --image=YOUR_IMAGE --command -- sh
# then run your start command by hand and watch it failSeparate "is it alive" from "is it ready"
A huge share of crash loops are self-inflicted: a liveness probe with too short a delay kills an app that's simply slow to boot. Use a readiness probe to gate traffic, and give liveness a generous startup window (or a startupProbe):
startupProbe:
httpGet: { path: /healthz, port: 3000 }
failureThreshold: 30
periodSeconds: 5 # up to 150s to boot before liveness kicks in
livenessProbe:
httpGet: { path: /healthz, port: 3000 }
periodSeconds: 10If it's OOMKilled, raise the memory limit or fix the leak. If it's a config error, the fix is in your logs from step 1 — crash loops are loud once you read the right container.
Supervise services without the Kubernetes restart-loop tax
If you're fighting CrashLoopBackOff, it's worth asking whether you need Kubernetes' complexity at all. Infraveil is a hosted backend operations control plane for applications running on your own servers: customer-side components start your services, health-check them, and apply configured restart budgets without Kubernetes probe tuning, backoff math, or YAML archaeology. A failed managed deploy can stop or use the configured rollback path instead of looping forever.
Frequently asked questions
What does CrashLoopBackOff mean?
Your container starts, exits, and Kubernetes restarts it repeatedly with a growing delay between attempts. The state describes the restart pattern; the actual fault is whatever makes the container exit.
How do I see why the pod is crashing?
Run kubectl logs <pod> --previous to read the crashed container's output, and kubectl describe pod <pod> to see the exit code and events.
What does exit code 137 mean?
137 means the process was killed by SIGKILL (128 + 9). Most often it's OOMKilled — the container hit its memory limit. Raise the limit or fix the memory leak.
Can a health check cause CrashLoopBackOff?
Yes. A liveness probe that starts too early or has too short a timeout will kill an app that's merely slow to boot. Use a startupProbe or a longer initial delay, and gate traffic with a readiness probe instead.
Client-side, no signup — they run in your browser.