What are the first 10 kubectl commands you run when troubleshooting a production issue?

Think of a doctor performing a physical exam. They do not start with an MRI. They check vital signs first: heart rate, blood pressure, temperature, breathing. These quick checks narrow the problem from thousands of possibilities to a few likely diagnoses. The first ten kubectl commands serve the same purpose: they give you a rapid situational awareness of what is broken, where it is broken, and what changed recently.

The first command, kubectl get pods -A (or scoped to the affected namespace), provides the highest-signal overview. It immediately shows CrashLoopBackOff, ImagePullBackOff, Pending, Evicted, or Terminating states. The -A flag catches problems in supporting namespaces like ingress, monitoring, or cert-manager that might affect the application indirectly. From this output, you identify which pods need deeper investigation.

The second and third commands, kubectl describe pod and kubectl logs --previous, give you the story of what happened. Describe shows events (scheduling failures, probe failures, volume mount errors), conditions, and container state transitions. Logs with --previous retrieve output from the last crashed container, which is essential because the current container might already be a fresh restart with no relevant history. Together, these two commands explain why a pod is unhealthy.

The fourth through sixth commands focus on the traffic path. kubectl get events --sort-by=.metadata.creationTimestamp reveals cluster-level problems like node pressure, quota exhaustion, or webhook failures. kubectl get endpoints verifies that the Service has healthy backends — empty endpoints is the silent killer that causes 503s with no application logs. kubectl describe ingress shows whether external routing is configured correctly and whether the controller has synced.

The seventh through ninth commands assess infrastructure. kubectl get nodes shows node readiness, version skew, and conditions like MemoryPressure or DiskPressure. kubectl top pods reveals which pods are consuming the most CPU and memory, potentially causing throttling or OOMKills. kubectl top nodes shows overall cluster capacity and whether scheduling failures are due to exhausted resources.

The tenth command, kubectl rollout status, connects the issue to recent changes. If a deployment is progressing (waiting for new pods to become ready) or degraded (deadline exceeded), it tells you whether the current incident correlates with a deploy. Combined with rollout history, you can quickly determine if a rollback is appropriate.

The non-obvious gotcha is command order and scope. Running these commands namespace-scoped when the problem is cluster-wide (node pressure, DNS failure, cert-manager down) wastes critical minutes. Conversely, running them cluster-wide when you already know the affected service adds noise. Senior engineers adapt the sequence based on the alert context: a PagerDuty alert with a namespace and deployment name lets you skip the broad scan and go directly to describe and logs.