Claude Prompt for a Kubernetes Troubleshooting Runbook

What this prompt does

This prompt turns the AI into a systematic Kubernetes troubleshooting runbook for a specific incident. You describe the [issue_description], the [cluster_type], the affected [workload_name], and its [namespace], and the model produces an ordered diagnostic path: initial kubectl triage, pod-level debugging keyed to your [pod_status], networking checks, resource analysis, a recent-changes audit, rollback commands, and a post-incident template.

The structure works because it enforces the order an experienced operator actually follows under pressure — describe, logs, events, then resource and networking checks before anyone touches a rollback. By anchoring step two to the real [pod_status] (for example CrashLoopBackOff), the model gives you the right branch of the diagnostic tree instead of a generic list. Naming [workload_name] and [namespace] means every command is copy-paste ready rather than a template you still have to fill in, which matters when you are debugging live and do not want to be editing placeholders. Anchoring the whole runbook to one [cluster_type] also means the commands account for that platform's quirks instead of staying generic.

When to use it

• A workload is crash-looping or failing right after a deployment and you need a calm, ordered path through it.
• Pods are stuck in a specific state like CrashLoopBackOff, ImagePullBackOff, or Pending and you want the matching checklist.
• A service is unreachable and you need to walk Services, Endpoints, NetworkPolicies, and DNS in order.
• Nodes look under pressure and you need to confirm whether it is a capacity or quota problem.
• You need the exact rollback commands and a way to verify the rollback actually succeeded.
• You want a post-incident action-items template so the same issue class does not recur.

Example output

Expect a runbook-shaped response: numbered sections, each with the specific kubectl get/describe/logs/events commands to run, a branching diagnostic tree for the [pod_status] you supplied, networking and resource checks, rollback commands with a verification step, and a fill-in post-incident template at the end. It reads like a checklist you can follow top to bottom during an incident.

Pro tips

• Be precise with [issue_description]; "pods crash-looping after the latest deploy" yields a far better tree than "app is down."
• Always set [pod_status] to the actual state from kubectl get pods so step two branches correctly instead of covering every failure mode.
• Fill [cluster_type] honestly — EKS, GKE, and bare-metal differ on node, IAM, and networking specifics, and the model tailors commands accordingly.
• Use the exact [workload_name] and [namespace] so the generated commands need no editing mid-incident.
• Run the diagnosis steps before the rollback step even when rollback feels obvious; the audit often reveals a config change you would otherwise repeat.
• Save the generated post-incident template into your repo so the runbook compounds over time rather than being regenerated each outage.
• Re-run the prompt with an updated [issue_description] if the first diagnosis points somewhere new; treating it as iterative beats forcing one pass to cover every symptom at once.