Getting Claude or Copilot to write a postmortem that doesn't read like a blame report

Background

Every team that's had a bad night eventually gets asked to "write it up." Hand that request straight to an AI tool with the raw timeline and chat logs and you'll usually get back a chronological account that reads like a court transcript - who clicked what, when, in what order things went wrong. It's accurate. It's also useless, because the first thing anyone reading it does is work out whose fault it was, and the postmortem's actual job - stopping it happening again - never gets touched.

The fix isn't a better model. It's asking for a specific, blame-resistant structure instead of "a summary of what happened," and being deliberate about what raw material you feed it and what you do with the draft once it comes back.

Setup

The full prompt template

You're drafting an incident postmortem from a raw timeline. This has to
read as a systems document, not an account of who did what.

Context: I'll give you a timeline, chat export, or ticket history for a
real incident. Draft a postmortem with exactly these sections.

Sections:
- What happened - one paragraph, no names, systems and components not
  people.
- Timeline - bullet points, times only, described as system states or
  events ("deploy started", "error rate crossed 5%"), never as a person's
  action.
- Impact - who was affected, for how long, in plain terms a non-technical
  reader can follow.
- Root cause - the actual mechanism that allowed the failure, not "human
  error." If the timeline only supports a partial or uncertain root cause,
  say so explicitly rather than guessing at one that sounds complete.
- What worked - what caught it, slowed it, or limited the damage. Don't
  skip this even if it's short.
- What we're changing - specific actions with an owner and a rough
  timeframe, not general intentions.

Constraints: never name an individual anywhere, including implied naming
("the engineer who normally handles this"). Describe roles or systems
instead. If the timeline doesn't give you enough to fill a section
honestly, say what's missing rather than inventing detail to complete it.

Input: [PASTE RAW TIMELINE / CHAT EXPORT / TICKET HISTORY]

What each instruction is actually doing:

• "No names, systems not people" stops the draft turning into an account of who did what, which is the single fastest way to make a postmortem meeting defensive instead of useful. "The deploy script skipped the health check" is a fact you can act on. "Dave forgot to check the dashboard" is a fact that ends the conversation about the missing health check.
• "Root cause, not 'human error'" is worth saying explicitly, because left alone the model will often land there anyway - it's the laziest correct-sounding answer for any incident. "Human error" describes every incident that has ever happened and prevents none of them. The actual question is: what made the error possible, and would a different person have hit the same wall?
• "What worked" is the section people skip writing and skip asking for, and it's the one that actually tells you whether your alerting, your runbook, or your on-call rotation did its job. A postmortem that's only a list of failures reads as more broken than the incident actually was.
• "Say what's missing rather than inventing detail" matters more here than in most prompting, because a fabricated but plausible root cause in an official incident document doesn't just look bad - it gets treated as settled and stops anyone looking further.

What to feed it, not just what to ask

The draft is only as good as the raw material behind it:

• The full chat export, not a paraphrase someone typed up afterwards. A summary written from memory an hour later has already lost the actual order things happened in, which is exactly what the timeline section depends on.
• Ticket or monitoring timestamps alongside the conversation, so the model can anchor "someone said the dashboard looked odd" to an actual time rather than guessing at sequence from message order alone.
• Anything that was said and turned out to be wrong during the incident. Leaving out the false leads makes the postmortem read as if the cause was obvious from the start, which quietly rewrites how hard the incident actually was to diagnose - and next time's on-call person loses the benefit of knowing that lead was a dead end.

Running the meeting from the draft, not around it

A drafted postmortem is a starting point for a conversation, not a document to read out loud and approve:

• Circulate it before the meeting, not during. The point of the meeting is disagreement and correction, and nobody does that well while reading something for the first time out loud.
• Ask explicitly "does this match what you saw?" to everyone who was actually there, not just the person who ran the prompt. A drafted root cause that nobody who lived through the incident has checked is a guess wearing an official document's clothing.
• Turn "what we're changing" into tracked work in the same meeting, not a follow-up someone means to do. An action item that isn't a ticket by the time the meeting ends usually isn't an action item three weeks later.

A lighter version for near-misses

Not everything needs the full six-section ceremony. For a near-miss - caught before it caused real impact - a shorter version keeps the habit of writing things down without the overhead putting people off doing it:

Draft a short near-miss note from this: what nearly happened, what caught
it before it became an incident, and one thing worth changing so it's
caught even earlier next time. No names, systems not people, two to three
sentences per section.

The value of the lighter version isn't the document - it's that a near-miss that never gets written up because "it wasn't a real incident" is exactly the kind of thing that becomes a real incident the third time it happens unnoticed.