Most Kubernetes incidents don't fail because the answer is hard to find. They fail because you're staring at kubectl describe output at 2 a.m., and the LLM you paste it into gives you a generic "check your resources" reply.
The difference between a useless chatbot answer and a working diagnostic plan is almost always the prompt. Give the model the right context — the actual events, the container exit code, the manifest, the chart version — and it stops guessing.
Below are 12 prompts I keep in a scratch file and paste into an LLM daily. Each one is complete, copy-ready, and comes with a real example. They won't replace your judgment, but they cut the boring part of SRE work down to copy-paste.
Why these prompts work (and generic ones don't)
An LLM has no access to your cluster. It only knows what you paste. So every prompt below follows the same structure: role + exact input + output format constraint.
The format constraint is the part most people skip. "Help me debug this pod" gives prose. "List the top 3 root causes ranked by likelihood, then give one kubectl command to confirm each" gives you something you can act on in 30 seconds.
The 12 prompts
1. CrashLoopBackOff triage
Use for: a pod that restarts in a loop and you don't know why.
You are a Kubernetes SRE. Here is `kubectl describe pod` output and the last 50 lines of logs. Identify the top 3 likely root causes ranked by probability. For each: what to confirm with a single kubectl command, and the fix. Output a table: Cause | Confirm command | Fix.
[PASTE describe output]
[PASTE logs]
Example: a pod with Exit Code: 137 and no logs. The model correctly points to OOMKill (137 = SIGKILL, usually memory), not a crash in your app. That single insight saves 20 minutes of log-hunting.
2. Resource requests and limits
Use for: sizing resources.requests and limits without guessing.
Given this container's observed usage over 24h (paste kubectl top output) and its workload type (web API / batch job / queue consumer), recommend requests and limits. Explain the QoS class this produces (Guaranteed / Burstable / BestEffort) and the eviction risk. Output YAML only for the resources block.
[PASTE kubectl top pod output]
3. YAML linter and API version fixer
Use for: manifests that fail kubectl apply with a schema error.
This manifest fails to apply. Rewrite it for Kubernetes 1.30, fixing deprecated apiVersions and invalid fields. Show a diff of what changed and why. Do not add fields I didn't ask for.
[PASTE manifest]
[PASTE apply error]
Common catches: extensions/v1beta1 Ingress moved to networking.k8s.io/v1, and policy/v1beta1 PodDisruptionBudget moved to policy/v1. The model flags both.
4. Helm chart skeleton generator
Use for: turning a raw set of manifests into a parameterized chart.
Convert these manifests into a Helm chart. Create Chart.yaml, values.yaml, and templates/ with proper {{ .Values }} references. Use _helpers.tpl for name and labels. Don't hardcode namespaces. Output the full file tree, one file per code block.
[PASTE manifests]
Example: three Deployments + a Service become a chart where image.tag and replicaCount live in values.yaml. This is the fastest way to package a prototype.
5. Helm values debugging
Use for: helm template output that doesn't match what you expected.
Here is my values.yaml, my template, and the rendered output from `helm template`. The rendered output has [describe the problem]. Explain which template line causes it, why, and give the corrected template.
[PASTE values.yaml]
[PASTE template]
[PASTE rendered output]
Most Helm bugs are indentation or a nil value the template doesn't guard against. The model spots unguarded .Values.x.y chains fast.
6. Service mesh / Ingress 502 debugger
Use for: a 502 or 503 between an Ingress and a Service that "looks fine."
A request to my Ingress returns [502/503]. Here is Ingress YAML, Service YAML, and Endpoints output. Walk the traffic path hop by hop (Ingress -> Service -> Endpoints -> Pod). At each hop, name the most likely failure and the command to verify. Don't skip the Endpoints check.
7. RBAC policy reviewer
Use for: a Role or ClusterRole you're about to ship.
Review this RBAC manifest. Flag any rule that grants more than needed (wildcards, cluster-wide scope, secrets access). Suggest the least-privilege version and explain what breaks if I apply it.
[PASTE Role/ClusterRole YAML]
8. NetworkPolicy from a plain-English rule
Use for: locking down pod-to-pod traffic.
Write a NetworkPolicy that allows only [describe traffic, e.g. 'pods labeled app=api to reach app=db on port 5432, nothing else']. Default-deny ingress and egress. Output YAML only.
9. kubectl command translator
Use for: when you know what you want but forget the exact flags.
Give me the exact kubectl command to [task, e.g. 'list all pods not in Running state across all namespaces with their node']. One command, no explanation unless it's non-obvious.
10. Postmortem drafter
Use for: turning an incident timeline into a blameless postmortem.
Turn this incident timeline into a blameless postmortem: Summary, Impact, Timeline, Root Cause, Action Items. Keep it factual, no blame. Action items must be concrete and assignable.
[PASTE timeline notes]
11. HPA and autoscaling sanity check
Use for: an HPA that never scales or scales too aggressively.
Here is my HPA and Deployment. Explain why it may not scale: check target metrics, min/max replicas, and whether requests are set (HPA needs requests to compute utilization). Give the corrected HPA.
12. Cost and right-sizing review
Use for: a periodic sweep of cluster spend.
Given these node types and pod requests across namespaces, identify over-provisioned workloads and suggest right-sized requests. Estimate rough monthly savings per workload and flag the top 3 changes by impact.
[PASTE node and pod summary]
What these prompts won't do
They won't touch your cluster, and they won't know your custom CRDs. Treat every output as a draft to verify, not gospel. The model is a fast first reviewer, not an authority.
If you want to go deeper into automating your own engineering workflow with AI — beyond copy-paste prompts — the AI for professionals program covers end-to-end automation. And if you're building the review habit, 12 prompts that catch bugs before merge pairs well with this set.
The real win isn't any single prompt. It's the habit of pasting real output — the events, the exit code, the rendered template — instead of a vague description. That one change turns a chatbot into a teammate that actually reads the logs.