Skip to content
DevOps AI ToolKit
Newsletter
All troubleshooting hubs Troubleshooting hub

Kubernetes Pod Startup & CrashLoop Errors

The complete set of "my pod won't start" failures: crash loops, image-pull failures, OOM kills, bad container config, failing init containers, and node evictions. Each guide leads with the one-line cause and the `kubectl logs --previous` / `describe` commands that prove it. Jump to your symptom below, or hand the logs to the assistant.

Fix your error now

Paste the error or logs and let the Incident Assistant diagnose it, or run a guided triage prompt with AI — no copy-paste.

Diagnose with the Incident Assistant →

Every guide in this cluster

11 guides

Kubernetes & Helm AI prompts

Copy-paste, production-safe prompts for this stack.

Kubernetes & Helm command center

Top errors, validators, and runbooks for the whole stack.

Frequently asked questions

How do I find why a pod is in CrashLoopBackOff?
The crashed container's own output is the answer. Run kubectl logs <pod> --previous to read the last run before the restart, and kubectl describe pod <pod> for the termination reason and exit code. Exit 137 is an OOM kill, exit 1/2 is usually an app or config error. See CrashLoopBackOff.
What is the difference between ImagePullBackOff and ErrImagePull?
ErrImagePull is the first failed pull attempt; ImagePullBackOff is Kubernetes backing off and retrying it. Both mean the kubelet can't fetch the image — a wrong name/tag, a missing imagePullSecret, expired registry credentials, or rate limiting. See ImagePullBackOff.
Exit code 137 keeps killing my container — what is it?
Exit 137 = 128 + 9 (SIGKILL), almost always the kernel OOM killer terminating the container for exceeding its memory limit. Raise the limit, fix the leak, or make the app cgroup-aware — the OOMKilled guide walks through each.