Your pod is crashing. Let's figure out why.
Answer a few questions about what you're seeing and get the exact diagnosis plus the kubectl commands to fix it. No login, no install, works for any cluster.
How PodTriage works
- 1
Pick your pod's status, or paste describe output
Choose the status shown in kubectl get pods, or paste your kubectl describe pod output and click "Detect status" to skip straight to the right flow.
- 2
Everything runs client-side
The status detection uses plain regex string matching in your browser. Nothing you paste, including pod names, namespaces, or internal hostnames, is ever sent to a server.
- 3
Answer 2-3 targeted follow-up questions
Each status has its own small decision tree built from real Kubernetes failure signatures, for example whether kubectl logs --previous shows an error or is empty for CrashLoopBackOff, or whether a memory limit is set for OOMKilled.
- 4
Get a plain-English diagnosis
No generic "here are five possible causes" list. Your specific answers narrow it down to one diagnosis with a clear explanation of what's actually happening.
- 5
Copy the exact commands to confirm it
Every diagnosis includes the specific kubectl commands to verify it's really your issue, with a copy button on each one.
- 6
Apply the fix, or start over for a different pod
Diagnoses that need a config change include a ready-to-adapt YAML snippet. Click "Start over" to run through a different scenario without reloading the page.
What each pod status means
A quick summary of the six statuses PodTriage covers. Pick the matching one in the tool above for the full branching diagnosis.
The container starts, then dies, over and over.
The container was killed for using too much memory.
Kubernetes can't pull the container image.
The pod hasn't been scheduled to a node yet.
The kubelet removed the pod to relieve pressure on the node.
The pod is frozen mid-transition and won't move on.
kubectl commands worth knowing before you start
Every diagnosis in PodTriage builds on these three commands. Getting comfortable with their output makes the follow-up questions much faster to answer.
| Command |
|---|
| kubectl get pods -n <namespace> |
| kubectl describe pod <pod> -n <namespace> |
| kubectl logs <pod> -n <namespace> --previous |
| kubectl top pod <pod> -n <namespace> |
When to use PodTriage
| Scenario |
|---|
| A deploy just went out and the pod immediately started crash-looping |
| A long-running service keeps getting restarted with rising memory beforehand |
| A new pod is stuck without ever reaching Running |
| You have a kubectl describe pod output already open and want the fast path |
| A node ran out of disk or memory and pods disappeared |
| On-call at 4pm, a pod just broke, no senior SRE around |
Frequently Asked Questions
What does CrashLoopBackOff mean?
CrashLoopBackOff means a container keeps starting, crashing, and getting restarted by Kubernetes, with an increasing delay between each restart attempt. It's not an error type itself, it's Kubernetes reporting that the normal restart policy has kicked in repeatedly. The actual cause (an application error, a bad entrypoint, a failing liveness probe) is almost always visible in kubectl logs --previous or the pod's Events.
What does OOMKilled mean in Kubernetes?
OOMKilled means the container was killed because it tried to use more memory than its resources.limits.memory allowed (or, without a limit set, more than the node itself could spare). You'll see Reason: OOMKilled and typically Exit Code: 137 under the pod's Last State. It can mean the limit is simply too low for real usage, or that the application is leaking memory over time, PodTriage's OOMKilled flow above walks through telling the two apart.
How do I use PodTriage to diagnose a crashing pod?
Pick the status shown in kubectl get pods (CrashLoopBackOff, OOMKilled, ImagePullBackOff, Pending, Evicted, or a stuck ContainerCreating/Terminating pod), or paste your kubectl describe pod output and let the tool auto-detect it. Answer 2-3 follow-up questions about what you're actually seeing in the logs or Events, and you'll get a plain-English diagnosis, the exact commands to confirm it, and the fix.
kubectl get pods -n <namespace>
kubectl describe pod <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --previousDoes PodTriage send my pod data or logs to a server?
No. The entire decision tree and the optional paste-and-detect feature run in JavaScript in your browser. If you paste kubectl describe pod output, it's pattern-matched locally with regular expressions, never uploaded or sent anywhere. This matters because describe output can contain internal hostnames, image registry paths, and other details you may not want leaving your machine.
How is PodTriage different from a CrashLoopBackOff troubleshooting article?
| Typical troubleshooting article | PodTriage | |
|---|---|---|
| Format | One long article covering every cause | A few questions, one relevant answer |
| Finding your cause | Read 5+ sections to find the one that matches | Click through symptoms, skip the rest |
| Cluster-specific | Often tied to one cloud provider's console | Provider-agnostic: GKE, EKS, AKS, bare metal, k3s |
| Auto-detection | None | Paste describe output, status is detected for you |
Static guides are thorough, and worth reading for background. PodTriage exists for the moment you don't want background, you want the two commands to run right now.
Which pod statuses does PodTriage cover?
- CrashLoopBackOff — The container starts, then dies, over and over.
- OOMKilled — The container was killed for using too much memory.
- ImagePullBackOff — Kubernetes can't pull the container image.
- Pending — The pod hasn't been scheduled to a node yet.
- Evicted — The kubelet removed the pod to relieve pressure on the node.
- Stuck ContainerCreating / Terminating — The pod is frozen mid-transition and won't move on.
These six cover the overwhelming majority of real-world pod crash searches. Node-level issues (NodeNotReady, disk pressure at the node level) may be added in a future version.