How to Use AI to Write a Clear Incident Postmortem

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.

What You Need Before You Start

Gather these before touching any AI tool:

• Raw timeline — Slack threads, PagerDuty alerts, log excerpts, anything timestamped
• Impact statement — who was affected, for how long, what broke
• Resolution summary — what you changed to fix it
• Contributing factors — what you already suspect caused it

You don't need prose. Bullet points and timestamps are perfect. The AI's job is to structure and clarify, not to invent facts.

Step 1 — Build the Timeline First

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.

Step 2 — Draft the Full Postmortem

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.

Step 3 — Sharpen the Root Cause Section

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>

Step 4 — Generate Action Items That Are Actually Actionable

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>

Step 5 — Final Readability Pass

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.

The Full Flow at a Glance

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