Writing a clear incident postmortem is one of those tasks that always lands at the worst time — right after an outage, when you're exhausted and the timeline is still fuzzy. AI handles this well if you give it the right inputs. Here's the exact workflow I use to go from raw incident notes to a publishable postmortem in under 30 minutes.
Gather these before touching any AI tool:
You don't need prose. Bullet points and timestamps are perfect. The AI's job is to structure and clarify, not to invent facts.
Paste your raw notes and use this prompt:
You are an SRE technical writer. Below are raw notes from a production incident.
Extract a clean, chronological timeline. Each entry: [HH:MM UTC] — one sentence, active voice,
technical but readable by non-engineers. Do not infer events not present in the notes.
Raw notes:
<paste notes here>
Review the output carefully. Remove anything the model inferred that isn't backed by your notes. This step usually saves 15 minutes of manual reordering.
Once the timeline is clean, run this:
Using the timeline below, write a production incident postmortem using this structure:
1. Summary (3 sentences: what broke, impact, how it was resolved)
2. Timeline (paste the cleaned timeline from Step 1)
3. Root Cause
4. Contributing Factors
5. Impact (users affected, duration, error rate or other metrics)
6. Resolution
7. Action Items (each item: owner placeholder, due date placeholder, one sentence)
Tone: clear, blameless, factual. No hedging language. No passive voice.
Timeline:
<paste Step 1 output>
Additional context:
<paste your impact statement, root cause notes, and resolution summary>
The blameless framing instruction matters — without it, models sometimes default to language that subtly assigns fault to individuals.
Root cause sections are where postmortems get vague. If the draft is soft, target it directly:
The root cause section below is too vague. Rewrite it to be specific:
- Name the exact system or component that failed
- Describe the failure mode (not just "misconfiguration" — what was misconfigured and why it mattered)
- One sentence on why existing monitoring didn't catch it earlier
Current root cause section:
<paste draft>
Vague action items are a postmortem's biggest failure mode. Run this on your draft action items:
Review these action items from a postmortem. For each one that is vague, rewrite it to be:
- Specific (names the exact system or process to change)
- Measurable (includes a success condition or metric)
- Scoped (can be completed in one sprint)
Action items:
<paste list>
Before sharing:
Read this postmortem as a skeptical engineer who wasn't on-call during the incident.
Flag any section that is unclear, assumes context, or uses jargon without explanation.
List each issue as a bullet with a suggested fix.
Postmortem:
<paste full draft>
Fix what's flagged. Done.
| Step | What it does | Time saved |
|---|---|---|
| 1 — Timeline extraction | Orders chaos into a clean sequence | ~15 min |
| 2 — Full draft | Structures everything into a standard format | ~20 min |
| 3 — Root cause sharpening | Replaces vague with specific | ~10 min |
| 4 — Action item audit | Makes follow-ups actually closeable | ~10 min |
| 5 — Readability pass | Catches assumed context before it ships | ~5 min |
The raw inputs still come from you. The AI handles the structural and prose overhead so you can focus on the analysis that actually prevents the next incident.
I break down one workflow like this every week in The AI Leverage Weekly — practical, no fluff, free. Subscribe: https://theaileverageweekly.beehiiv.com/subscribe?utm_source=devto&utm_medium=article&utm_campaign=medium_w14