How to Prompt AI to Write a Postmortem

The reason most AI-written postmortems are useless is that they are asked for too early. Given a Slack thread and a request to "write a postmortem", a model produces a clean narrative with a plausible root cause and three sensible-sounding action items. It reads well. It is also, frequently, wrong about the cause, because it inferred one from the shape of the conversation rather than from evidence.

Used properly, AI is very good at two parts of this and bad at a third. It builds the timeline, it drafts the write-up, and it should not be the thing that determines the cause.

First, build the timeline separately

The timeline is the artefact everything else depends on, and assembling it is genuinely tedious work that a model does well.

Give it the raw material: alert timestamps, deploy log, the incident channel export, the relevant graphs described in text. Then constrain it hard.

Build a timeline of this incident from the material below. One row
per event, with columns: timestamp (UTC), source, what was observed,
and who observed it. Include only events that appear in the source
material. Do not infer causes, do not add events you think must have
happened, and do not merge events. Where a timestamp is missing or
ambiguous, write UNKNOWN rather than estimating.

The last two instructions matter more than the rest. Left unconstrained, a model produces a smooth narrative by inventing the connective tissue, and the invented parts are indistinguishable from the real ones once they are in the table.

Then read the timeline against the sources. This is the step that decides whether the postmortem is worth writing, and it takes about ten minutes.

Second, determine the cause yourself

This is the part to keep. A postmortem's value is entirely in whether the cause is right, and a model reading a chat log will land on whatever the humans in that log speculated about at the time, which is often the first plausible theory rather than the correct one.

What AI is useful for here is pressure-testing a cause you have already formed:

Our stated cause is: <cause>. Using only the timeline, identify
every event that is inconsistent with this explanation, and every
point where the timeline is silent about something this explanation
requires to be true.

That is a genuinely useful prompt. It is looking for holes in your reasoning rather than generating reasoning, which is the shape of task where models are reliable. It works for the same reason described in prompting AI to check its own work and prompting AI to play devil's advocate.

Push past the first answer. "The deploy caused it" is a description, not a cause. Why did the deploy pass review, why did no test catch it, why did it take nineteen minutes to notice. The cause you can act on is usually three questions deeper than the one that ends the incident channel.

Third, draft the document

With a verified timeline and a cause you believe, drafting is mechanical and worth handing over.

Write an incident postmortem using the timeline and cause below.
Structure: summary (3 sentences, no jargon), impact (who was
affected, how many, for how long), timeline, root cause, what went
well, what went badly, action items.

Rules: blameless language, no individual names, use roles instead.
Every factual claim must trace to a timeline row. Where the timeline
does not support a claim, omit it. Do not invent action items; use
only the ones listed below.

The blameless constraint needs stating explicitly. Unprompted, models write "the engineer deployed without testing", which is accurate, useless and guarantees the next incident gets reported later and less honestly.

"Do not invent action items" is the other important one. Models are enthusiastic about generating remediation lists, and an unfiltered list of twelve plausible improvements that nobody owns is how postmortem culture quietly dies. Bring your own three, each with an owner.

What to check before you circulate it

Five things, quickly:

1. Every timestamp appears in a source you can point at.

2. The impact numbers are measured, not estimated. If they are estimated, the document says so.

3. No individual is named or identifiable by role plus context.

4. Each action item has an owner and a date. Items without both are wishes.

5. The stated cause survives the inconsistency check from the second section.

If your team does not have a template yet, generate one once and reuse it rather than regenerating the structure every time. A stable format makes incidents comparable across months, which is where the pattern-level insight actually comes from. The same argument applies to prompting AI to write a runbook, and an AI incident response plan is the document this one feeds back into.

For turning the resulting action items into tracked work, prompting AI to turn meeting notes into action items covers the extraction step. And for the general principles behind these constraints, see our prompt engineering framework.

FAQ

Can AI write a postmortem from just the Slack thread?

It will produce one, and the cause will reflect what people speculated during the incident rather than what actually happened. Use the thread for the timeline; determine the cause separately.

How do I stop it inventing timeline events?

Instruct it explicitly to include only events present in the source material and to write UNKNOWN for missing timestamps rather than estimating. Then check the output against the sources.

Should the postmortem name who caused the incident?

No. Blameless postmortems produce more honest and earlier reporting. Use roles rather than names, and say so in the prompt, because unprompted output will name people.

What is the most common failure in an AI-drafted postmortem?

A confident root cause that is really a description of the trigger. "The deploy broke it" is where the analysis starts, not where it ends.