Incident postmortem prompt builder
A good postmortem turns an outage into prevented future outages — but writing one under post-incident fatigue is when corners get cut. This builder takes your raw incident facts and generates a prompt that produces a blameless, structured postmortem: summary, quantified impact, timeline, 5-whys root cause, contributing factors, what went well, and owned action items tagged by type.
How it works
You provide the incident summary, timeline events, contributing factors, and
impact metrics. The tool assembles a prompt instructing the model to write a
systems-focused, blameless report with a fixed section structure, to distinguish
the trigger from the underlying root cause using 5-whys, and to tag each action
item as prevent, detect, or mitigate. Crucially it tells the model not to invent
events or metrics and to mark gaps as [TODO: confirm], so the draft stays
grounded in what actually happened. The prompt is built in your browser.
Trigger vs. root cause: why the distinction matters
Nearly every postmortem cites the trigger as the cause. “A bad config deploy caused the outage” describes the trigger — the immediate event. The root cause is the answer to “why could that config deploy cause an outage?” — perhaps configs deploy without a staging gate, or deploy tooling has no rollback mechanism, or monitoring does not alert until SLA is breached.
The 5-whys technique in the prompt pushes the model past the trigger:
- Why did the outage happen? → A bad config deployed to production.
- Why did a bad config reach production? → No staging environment for config changes.
- Why is there no staging gate for configs? → Config deploys were excluded from the CI pipeline.
- Why were they excluded? → No policy requiring config changes to go through CI.
- Why was there no policy? → Root cause: config management was informal and not reviewed in prior incidents.
Action items that address cause 5 prevent recurrence. Action items that address only cause 1 address symptoms.
The prevent / detect / mitigate taxonomy
A well-balanced postmortem has action items in all three categories:
| Category | What it addresses | Example |
|---|---|---|
| Prevent | Stops the failure mode from occurring | Add a CI gate for config changes |
| Detect | Shortens time-to-detection when it does occur | Alert on config deploy + error-rate correlation |
| Mitigate | Reduces blast radius or recovery time | Add automatic rollback on error-rate spike |
A postmortem with only prevention items will recover slowly when (not if) a different failure mode hits. Covering all three makes the system more resilient at every layer.
Tips and notes
- Ground it in facts. The more accurate your timeline and impact data, the less the model has to mark as TODO and the better the root-cause analysis.
- Push past the trigger. The 5-whys instruction stops the report at the systemic cause, not just the immediate event.
- Balance the action items. Aim for coverage across prevent, detect, and mitigate — not five prevention tasks and nothing else.
- The owner signs off. The model drafts; the incident owner verifies the timeline and root cause and owns the follow-ups.
- Publish, do not archive. A blameless culture depends on postmortems being read and learned from, not quietly filed. Make them accessible to the whole engineering team.