Troubleshooting Wizard
Answer a few questions to find the most relevant diagnostic playbook and restoration steps.
What type of issue are you experiencing?
About the Troubleshooting Wizard
This wizard walks through the diagnostic questions an experienced engineer asks when a Kubernetes workload is not behaving, in the order that eliminates the most possibilities soonest. It is a substitute for having done it a hundred times, not for understanding the cluster.
The ordering matters more than any individual check. Most Kubernetes debugging goes wrong by starting at the application — reading logs and forming theories — when the pod never started, was never scheduled, or is failing a probe. Establishing where in the lifecycle things stopped narrows the problem far faster than reading output.
The sequence is always the same: did the pod get scheduled, did the image pull, did the container start, did it stay running, did it pass its probes, and is traffic reaching it. Each stage has its own signature and its own place to look.
Frequently asked questions
Where should I look first when a pod is not working?
The events in kubectl describe, before logs. Events explain scheduling failures, image pull failures, and probe failures directly, and all three happen before an application produces any logs at all. Reading logs first is why so much time is spent looking for an application bug that does not exist.
What does Pending actually mean?
The pod has been accepted but not scheduled onto a node, so nothing has started. The cause is almost always insufficient resources for its requests, a node selector or affinity rule matching nothing, an unsatisfied taint toleration, or a persistent volume claim that cannot bind. The scheduler records the reason in the pod's events.
How do I distinguish an application crash from a probe failure?
Look at the restart reason and exit code. An application crash usually shows a non-zero exit code and produces logs from the previous container. A liveness probe failure appears in events as a probe failure with the endpoint named, and the container may have been perfectly healthy but too slow to answer under load.
The pod is Running but requests fail — what next?
Running means the container process started, not that it is ready. Check whether the pod is in the Service endpoints — a failing readiness probe removes it while leaving it running. If endpoints look right, check the Service selector matches the pod labels and that the target port matches the container's actual listening port.
When is the problem the cluster rather than the workload?
When several unrelated workloads degrade together. A single failing deployment is nearly always its own configuration. Simultaneous failures across namespaces point at a node under resource pressure, a DNS or CNI problem, an expired certificate, or a control plane issue — and the investigation moves to nodes and cluster components rather than manifests.
Need this managed for you, not just automated?
We're also a hands-on DevOps consultancy — Kubernetes, CI/CD, and cloud infrastructure.