What makes a postmortem blameless?

A blameless postmortem focuses on what the system and processes allowed to happen, not on who made a mistake. The generated prompt enforces this — no names, no blame — because blame discourages honest reporting and hides systemic causes.

Will the model invent timeline entries?

No, the prompt explicitly tells it not to fabricate timeline events or metrics and to mark anything missing as [TODO: confirm]. The quality of the draft depends on the events and data you provide.

What is the difference between trigger and root cause?

The trigger is the immediate event that set the incident off (e.g. a config deploy); the root cause is the underlying reason it could cause harm (e.g. configs deploy without staging validation). The prompt uses 5-whys to push past the trigger to the root cause.

Why tag action items prevent / detect / mitigate?

Categorizing follow-ups makes coverage visible: prevent stops recurrence, detect shortens time-to-detection, and mitigate reduces blast radius. A good postmortem usually has items across all three, not just prevention.

Should the AI draft be the final report?

No. Treat it as a structured first draft. The incident owner must verify the timeline, confirm the root cause, fill the TODO markers, and own the action items before publishing.

Incident Postmortem Prompt Builder

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.

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.