How to Write a Blameless Incident Postmortem Prompt That Holds Its Shape

An incident closes. The channel goes quiet. Then someone has to write the postmortem, and the doc that comes back is either a wall of Slack-paste or a sanitized summary that blames the on-call engineer and teaches nobody anything. That's the gap an incident postmortem prompt fills: it takes the messy timeline and produces the same blameless, owner-tagged writeup every time.

Most of what ranks for this query is a static template you fill in by hand, or a vendor walkthrough that funnels you into their incident tool. Useful, but you still do the writing. A reusable prompt does the structuring for you, in whatever model you already have open, with the blameless tone baked into the instructions instead of left to your discipline at 2am.

This is a reference for building that prompt and the output contract that keeps it honest.

Why postmortems drift without a contract

A postmortem has a fixed anatomy: what happened, when, why, and what changes so it doesn't happen again. Ask a model for "a postmortem" with no structure and you get prose that reorders those parts every run. One version leads with root cause. The next buries it under three paragraphs of timeline. You can't compare two postmortems written a week apart because they aren't the same document.

The fix is an output contract. Name the sections, name their order, and the model fills them rather than inventing a layout. The contract also carries the blameless rule, which is the part humans skip when they're tired and the part that determines whether anyone trusts the doc.

Here's the opinionated part. A blameless postmortem isn't a tone you ask for politely. It's a constraint you enforce. "Please be blameless" gets ignored the moment the timeline mentions who ran the deploy. A hard rule that rewrites person-language into system-language is the only thing that survives a real incident with real names in it.

What you can do with this prompt

• Turn a raw incident channel export into a structured timeline with timestamps
• Separate the trigger from the root cause from the contributing factors
• Generate action items that each carry an owner and a due window
• Rewrite blame language ("Sam pushed a bad config") into system language ("a config change reached prod without a staging gate")
• Produce a one-paragraph executive summary for the status page or leadership update
• Keep severity, detection time, and time-to-resolve as structured fields for trend tracking

Anatomy of the postmortem prompt

The prompt has three moving parts. The variables hold the incident facts. The instructions set the blameless boundary and the analysis steps. The output contract locks the document shape.

Variables → Prompt → Output

{{incident_summary}}     one-line description of what broke
{{timeline_raw}}         pasted alerts, Slack, deploy logs (unstructured)
{{severity}}             SEV1 / SEV2 / SEV3
{{detection_method}}     how it was noticed (alert, customer, manual)
{{services_affected}}    the systems users actually felt

→ Blameless analysis instructions + refusal boundary →

→ Output contract:
   ## Summary
   ## Timeline (UTC)
   ## Root cause
   ## Contributing factors
   ## What went well
   ## Action items (owner | item | due)
   ## Detection & response metrics

The contract goes last in the prompt on purpose. Models weight the most recent tokens, so when you paste a long {{timeline_raw}}, the format spec sitting after it stays in focus. Put the contract first and a 4,000-token timeline can push it out of attention.

Step-by-step usage

1. Gather inputs

Export the incident channel, the alert payloads, and the deploy log. Don't clean them up. The whole point is that the prompt does the cleanup. Drop the severity and detection method in as separate fields so they land in the metrics section instead of getting lost in prose.

2. Fill variables

Paste the raw dump into {{timeline_raw}}. Set {{severity}} and {{services_affected}}. Keep {{incident_summary}} to one line. The model expands it; you don't need to pre-write the narrative.

3. Run the prompt

Run it at a low temperature. Postmortems are extraction-and-structuring work, not creative writing, so you want the same input to give you the same shape. Temperature 0 to 0.3 is the band that keeps the timeline faithful.

4. Post-process

Read the root cause against the timeline. The model will sometimes promote a contributing factor to root cause when the real trigger is buried. Move it back. Check that every action item has an owner. An unowned action item is a wish.

5. Iterate

If the timeline came out thin, the raw paste was probably missing the detection moment. Add the first alert's timestamp and rerun. You're tuning inputs, not rewriting the prompt.

Prompt-craft patterns that matter here

The refusal boundary. This is what makes it blameless instead of blame-shaped.

Never name an individual as a cause. If the input names a person who took
an action, describe the action and the system gap that allowed it, not the
person. Flag any sentence you cannot phrase this way under "Needs human review".

The metrics extraction. Pull detection time and resolution time into named fields so you can trend them across incidents. A postmortem that buries "detection took 40 minutes" inside a paragraph can't be aggregated. One that emits a Detection & response metrics block can.

The two-pass timeline. First pass, the model orders raw events by timestamp. Second instruction, it collapses duplicate alerts into single rows. Without the collapse rule, a noisy alert that fired 30 times becomes 30 timeline entries and drowns the actual signal.

Variables you'll set

Getting started

1. Copy the prompt into your model of choice and set the temperature low.
2. Paste the raw incident dump into {{timeline_raw}} without cleaning it.
3. Fill {{severity}} and {{services_affected}}.
4. Run it, then check root cause against the timeline.
5. Confirm every action item has an owner and a due window.
6. Save the output as the postmortem; keep the metrics block for trend tracking.
7. For recurring incident types, start from the Incident Postmortem Agent Pack, which ships the refusal boundary and the metrics contract already wired.

If postmortems are a weekly job rather than a rare one, building the prompt from scratch each time is wasted effort. The pack version also pairs cleanly with on-call work, where the same timeline data feeds a different output.

Postmortems rarely live alone. The same alert export that feeds this prompt also feeds an on-call handoff, so it's worth reading how to build an on-call handoff brief prompt next, and if you're still deciding between a one-off prompt and a maintained pack, how to choose a reusable AI prompt pack walks through the trade-off. You can also browse the full Engineering On-Call Coordination Agent Pack if the incident is part of a wider on-call rotation.