Prompt patterns for IT runbooks
A handful of templates that survived contact with real incidents.
I’ve been collecting prompt templates that hold up under real incident conditions — not just in testing. Here are the ones that made the cut.
The diagnosis frame
When something is broken and you need to think through it systematically:
You are helping diagnose a production issue.
Context: [paste relevant logs/errors/symptoms]
System: [brief description of what this system does]
What we've already tried: [list]
Suggest three hypotheses for the root cause, ordered by likelihood.
For each, include: what it would explain, what it wouldn't explain,
and one specific thing to check to confirm or rule it out.
The key is “what it wouldn’t explain.” This forces the model to surface gaps in each hypothesis rather than just listing possibilities.
The runbook generator
For turning a working fix into a repeatable runbook:
I just fixed the following issue: [describe]
Steps I took: [list]
Environment: [Azure/on-prem/hybrid, relevant services]
Write a runbook for this that:
- Starts with the symptoms that would trigger it
- Lists prerequisites and access required
- Numbers each step with a verification step after anything non-trivial
- Ends with how to confirm the fix worked
- Notes anything that could go wrong and what to do
Important Always verify the output against what you actually did. The model will sometimes reorder steps in ways that seem logical but don’t match how the system actually works.
The incident summary
For writing up after an incident when you’re tired and just want to go home:
I'm writing a post-incident summary.
Incident: [one sentence description]
Duration: [start] to [end]
Impact: [who/what was affected]
Timeline of key events: [rough bullet points]
Root cause: [what actually happened]
Fix: [what resolved it]
Write a summary in this format:
- Executive summary (2 sentences max)
- Impact
- Timeline
- Root cause analysis
- Resolution
- Follow-up actions (leave these blank for me to fill in)
What makes these work
Three things these templates have in common: they give the model a clear role, they constrain the output format, and they leave room for my expertise rather than trying to replace it.
The worst prompts I’ve written try to hand everything to the model. The best ones use the model for the parts that are mechanical and keep the parts that require judgment in my hands.