How do I write a blameless postmortem after an outage?

A postmortem is easiest to write in the hour after the incident and hardest a week later. By then the chat has scrolled away and the timeline lives in three people's heads. The fix is to write the first draft from the raw material while it still exists, and to mark everything you are unsure about.

Google's SRE book gives the aim in one sentence: document the incident, understand the contributing causes, and put effective preventive actions in place. It also defines the word that matters here. A blameless postmortem identifies contributing causes without indicting any individual or team. In practice that means you describe what the system and the process allowed, not who clicked what.

What you need

• The raw material: the incident chat export, alert text, status page updates, deploy or commit notes, and your own rough notes. Paste it as it is.
• The time zone the timestamps are in. If you do not know, say so.
• Your team's postmortem template headings, if you have them.

The prompt

You write a blameless postmortem from the raw material below. Use only what the material says. Never invent a timestamp, metric, customer count, tool name, cause or person.

Service: [name]
Time zone of the timestamps: [zone, or "not stated"]
Template headings to follow (optional): [paste, or "none"]

Do this:
1. List every timestamped event in order, with the time exactly as written.
2. Tag every statement as Stated (it is in the material), Inferred (reasonable but not written down, with what it rests on) or Unknown.
3. Work out time to detect, acknowledge, mitigate and resolve using only stated times. Show the arithmetic. Mitigation means the impact went down. Resolution means the cause is fixed.
4. Give one root cause only if the material states it or clearly shows it. Otherwise write "most likely cause" and mark it Inferred. List contributing factors down to a process or system condition, such as a missing alert, an unclear runbook or a risky deploy step.
5. Use blameless language: describe actions and systems, use roles rather than names, and never write "human error" as a cause.
6. Write action items. Each gets a type (Prevent, Detect, Mitigate or Process), a concrete first step, a suggested priority and "Owner: [assign]". Do not invent owners or dates. Tie each action to a cause or factor.

Output these sections: Summary (3 to 4 sentences), Impact (only what is stated, otherwise "Not stated"), Timeline (table: time, event, source), Detection and response times, Root cause and contributing factors, What went well, What went badly, Action items, Open questions, Not in the material.
If the material contradicts itself, show both versions. If detection took a long time, say so plainly.

MATERIAL:
[paste here]

How to check the result

Read the timeline against the original chat. Every time should match a line you can find. Then read the "Inferred" tags. These are the sentences the team has to confirm or strike before the document is final.

Check the arithmetic yourself. Detection time is the one people get wrong, because the status page often opens later than the real start. If the material gives two start times, the draft should show both and say which one it used.

Then read the action items. A good one has a first step you could do on Monday. "Improve monitoring" is not an action. "Add an alert on review completion rate, starting with the job queue" is.

Sharing it

Circulate the draft to the people who were on the incident before anyone else sees it. Ask them one thing: is anything in the timeline wrong? Fix those, assign owners in a meeting, and only then publish.

Limits

• It only knows the material you paste. If the logs and metrics are not in the draft, they are listed under "Not in the material", and someone has to go and get them.
• It does not decide the root cause. When the evidence does not settle it, the draft says "most likely" and marks it Inferred. Treat that as a question for the team.
• Owners and dates are blank on purpose. Assign them in a meeting.
• A draft is not a review. The blameless part depends on how your team talks about it, not on the wording of a document.
• Do not paste customer data, secrets or personal details into a chatbot you do not control. Redact first.

Browse all skills in the catalog