How to Write an Incident Postmortem With AI
The incident's over and you've got a channel full of messages and logs, so "summarize this" returns a blamey story with an invented root cause. Here's how to turn your real notes into a blameless incident postmortem: confirmed timeline, evidence-backed factors, owned actions.
Build a Postmortem PromptWhen the incident's over but the write-up is a mess
The alert cleared an hour ago. What's left is a chat channel with two hundred messages, a few log excerpts someone pasted, a rollback that fixed it, and a vague sense of what went wrong. Someone asks for the postmortem, so you paste the channel into an AI and type "summarize this incident." What comes back reads smoothly and is quietly wrong in three ways: it names a root cause the evidence doesn't actually support, it puts the events in a plausible-but-not-real order, and it slides into blame — "the deploy by Sam caused an outage" — when what you needed was a record of how the system let that happen. It looks like a postmortem. It isn't one yet.
That's the gap this guide closes. An incident postmortem is a retrospective built after the fire is out: an agreed timeline, the real impact, the factors that actually contributed with the evidence behind each, and the changes that stop it recurring — written blamelessly, because the point is a safer system, not a named culprit. The model can draft that fast, but only from what you give it: the timeline you reconstruct, the log lines you paste, the impact you measured, the investigation notes you took. NewPrompt gives you the prompt structure to shape that draft; it doesn't watch your incident, connect to your logs, monitoring, or alerts, run the response, or track the actions afterward. The AI's proposed cause is a candidate to verify, not a finding to publish, and the timeline, the root cause, and the corrective actions are all things the postmortem's owner confirms before anyone relies on them.
Why "summarize the incident" produces a confidently wrong record
A summary and a postmortem are built for opposite jobs. A summary compresses a conversation into readable prose; a postmortem reconstructs what happened, weighs evidence, and assigns follow-up. Ask for the first and you lose the parts that make the second useful. Five failures show up almost every time:
- It invents a root cause. A confident "the root cause was the database migration" reads like a finding, but the model inferred it from the loudest messages — not from evidence anyone confirmed. The single most dangerous line in a bad postmortem is a cause presented as proven when it's a guess.
- It scrambles the timeline. Chat is out of order, timestamps are missing, and the model fills the gaps with a plausible sequence — so "the cache was cleared before the spike" becomes fact when nobody checked which came first.
- It drifts into blame. Left unguided, the model writes "Sam's deploy caused the outage," which is both unkind and useless: it names a person instead of the missing safeguard that let one deploy take the system down.
- It flattens impact into vibes. "The site was down for a while" is not impact; "checkout failed for ~40 minutes, affecting ~3,000 orders" is — and the model won't produce the second unless you supply the numbers.
- It drops the actions, or writes vague ones. "Improve monitoring" is a wish; a corrective action needs a specific change, an owner, and a way to know it's done — and a summary has no slot for any of that.
Step 1: Assemble the facts only you have
The model can only work from what you hand it, so gather the raw material before you prompt: the rough timeline you can reconstruct (even with gaps), the log lines or error excerpts that matter, the impact you can actually measure (duration, requests failed, customers or orders affected), and your investigation notes — including the things you checked and ruled out. Mark the timeline honestly: which timestamps are exact, which are approximate, and where there's a gap. A postmortem built on a guessed timeline inherits the guess, so the quality of this input sets the ceiling for everything after.
Be just as deliberate about what you don't know yet. Note the questions still open — "did the config change land before or after the first timeout?" — as open questions, not resolved ones. The temptation, an hour after an incident, is to smooth the uncertainty into a clean story; resist it here, because the draft will faithfully harden whatever certainty you feed it. Giving the model your genuine uncertainty is what lets it keep the hypotheses separate from the facts in the next steps instead of quietly merging them.
Step 2: Draft it in fixed sections that don't invent
Ask for the postmortem as a fixed set of sections rather than a narrative: summary, timeline, impact, contributing factors, corrective actions, and follow-up. The structure is what forces the distinctions a paragraph blurs — a timeline has to be ordered events, impact has to be numbers, factors have to be listed one by one. Just as important, tell the model to work only from the material you gave it and to write "not established" wherever a section would otherwise be filled by a guess. Severity and impact especially should be reported as you stated them, never assigned by the model on its own read.
The Structured Summary Prompt builds a prompt with exactly that shape — fixed sections, length caps, and a no-invention fidelity rule so the output compresses what's there instead of adding to it — which is the discipline a postmortem lives or dies on. The Incident Report Summary resource is that setup already tuned for incidents: it holds the timeline in chronological order and takes severity from the report rather than the model's judgment, and it's explicit that it summarizes the incident — it doesn't respond to one. Both hand you a prompt you run in your own AI tool; the sections come back structured, and what fills them is still yours to check.
Step 3: Separate proven cause from hypothesis and unknown
This is the step that turns a plausible story into an honest one. For every contributing factor, make the model attach the evidence — the log line, the metric, the change record that supports it — and label its status: established (the evidence backs it), likely (it fits but isn't confirmed), or disputed/unknown (it's a hypothesis, or people disagree). A factor with no evidence behind it doesn't get written as a cause; it gets written as an open question. The goal isn't a single confident root cause — it's an accurate map of what you know, what you suspect, and what you still have to find out.
The Root Cause Analysis Prompt models this rigor: it asks for the most likely cause plus the alternatives, each with the evidence for and against, and it keeps the unknowns as unknowns instead of resolving them to look complete. A stance like that — root cause first, and only from the evidence — is what the Debugging Prompt Generator is built to produce, if you want the contributing-factors analysis as its own focused pass before you fold it into the postmortem. Read whatever comes back as a candidate analysis: the model can misread a correlation as a cause or miss the factor nobody logged, so the person who owns the incident is the one who confirms which factors are real.
Step 4: Keep the language blameless
A blameless incident postmortem describes what the system allowed, not who to fault — because "Sam pushed a bad deploy" ends the investigation, while "a deploy could reach production without a load test that would have caught the regression" opens the real fix. Instruct the model plainly: describe actions and conditions, not people; replace any name-and-blame phrasing with the missing safeguard or the confusing signal that made the mistake easy to make. The same event becomes a systems finding instead of a personal one, and that's the version people will actually be honest in next time.
Blameless doesn't mean vague or evasive. "Mistakes were made" is not blameless, it's just unclear; the goal is precise about the mechanism and neutral about the person. A good check to add to the prompt: for each contributing factor, does it point at a change to the system — a guardrail, an alert, a clearer runbook — rather than at an individual's care? If a line only reads as "someone should have been more careful," it isn't a corrective finding yet, and the draft should surface that so you can turn it into one.
Step 5: Turn findings into owned, verifiable actions
A postmortem that ends in insight and no change is a story, not a safeguard. So convert each established or likely factor into a corrective or preventive action with three things attached: the specific change (not "improve monitoring" but "add an alert on connection-pool saturation above 90%"), the owner who will make it, and how you'll know it's done — the check that proves the fix works, like "the alert fires in a staging load test that reproduces the incident." Ask the model to draft actions in that shape and to flag any it can't make specific, so a vague one gets sharpened rather than shipped.
Two honest limits belong here. The model proposes owners and actions from the text; whether the owner is right, whether the action is feasible, and whether it's the highest-value fix are calls the team makes, not the draft. And NewPrompt structures the actions — it doesn't assign them in a tracker, set a due date in a calendar, or follow up on whether they got done; those live in your own process. The postmortem's value is realized when the actions leave the document and someone owns them; the draft gets you a clean, specific list to hand off, and the handoff is yours.
Common mistakes
The habits that turn an incident postmortem into a confidently wrong record:
- Publishing the AI's root cause as fact. It's a candidate inferred from the notes; require evidence per factor and let the owner confirm what's actually established.
- Trusting a reconstructed timeline. Chat is out of order and timestamps are missing; mark what's exact, approximate, and unknown, and don't let the model smooth a gap into a sequence.
- Letting the tone slide into blame. "Sam's deploy" names a person; rewrite every factor as the missing safeguard or confusing signal that let it happen.
- Reporting impact as a feeling. "Down for a while" isn't impact; supply the duration, the failed requests, and who was affected — the model won't invent real numbers, and shouldn't.
- Ending with vague actions. "Improve monitoring" is a wish; each action needs a specific change, an owner, and a way to verify it's done.
- Treating the draft as the record. It's a candidate the incident owner reviews, corrects, and approves — NewPrompt doesn't watch the incident or track the fixes.
A worked example: a post-deploy checkout timeout
Take the raw notes from a real-feeling incident and shape them into a postmortem that keeps the proven cause apart from the guess.
Raw incident notes summarized into an invented, blamey cause vs. a fixed-section postmortem that labels evidence, keeps the hypothesis open, stays blameless, and gives each action an owner and a checkRAW NOTES (what you actually have):
- 14:02 deploy went out (new order-search query)
- ~14:10ish checkout started timing out, alerts fired
- someone said the config change might be involved (not confirmed)
- 14:35 rolled back the deploy, checkout recovered by ~14:40
- logs show "connection pool exhausted" around 14:12
- ~3,000 checkout attempts failed during the window
WEAK ASK, AND WHAT IT RETURNS:
ask: "summarize this incident and give the root cause"
-> "Root cause: the config change caused a database outage. Sam's deploy
took down checkout for a while." (invents the cause, blames a person,
vague impact, wrong-ish timeline)
A POSTMORTEM DRAFT (fixed sections, evidence-labeled, blameless):
SUMMARY
Checkout timed out for ~30 min after a deploy; resolved by rollback.
TIMELINE (mark exact vs approx)
14:02 (exact) deploy with new order-search query
~14:10 (approx) checkout timeouts begin; alerts fire
14:12 (log) "connection pool exhausted"
14:35 (exact) deploy rolled back
~14:40 (approx) checkout recovers
IMPACT
~30 min; ~3,000 checkout attempts failed (as reported).
CONTRIBUTING FACTORS
- [established] new order-search query exhausted the DB connection pool
evidence: "connection pool exhausted" at 14:12; recovery on rollback
- [hypothesis / unconfirmed] the config change compounded it
evidence: raised in channel, not verified -> OPEN QUESTION
- [systems] a deploy reached prod without a load test that would have
surfaced the pool exhaustion (not "Sam deployed a bad query")
CORRECTIVE ACTIONS
- add alert on connection-pool saturation >90%
owner: platform lead | verify: alert fires in a staging load test
- add a load-test gate for queries on hot paths before prod
owner: checkout team | verify: gate blocks a known-bad query in CI
OPEN QUESTIONS
- did the config change land before or after the first timeout?
STILL YOUR JOB:
confirm the timeline, verify the established factor against the real logs,
resolve the open question, and assign the actions in your own tracker.
the draft organized what you knew; it did not prove the cause.Where this fits in NewPrompt
Writing the incident postmortem is the last phase, and it helps to see the phases around it. The AI Production Incident Workflow is the whole arc — triage and stabilize, understand the failing path, write the incident summary, then produce the postmortem — and this guide is that final step done well, once the fire is out and the writeup can be honest. The pieces it uses are small: the Structured Summary Prompt holds the fixed, no-invention section shape; the Incident Report Summary tunes it for incidents; the Root Cause Analysis Prompt and the Debugging Prompt Generator do the evidence-first factor analysis. None of them watches your systems, reads your logs, or runs the response — they structure the write-up you produce from the facts you supply.
It's worth separating this from the moves it isn't. A rollback plan is written before a change ships, to decide how you'd undo it; debugging is the live hunt for a cause while something is broken; incident response is stabilizing the system while the fire burns. The postmortem comes after all of those: it's the retrospective that turns a resolved incident into a record and a set of changes, blamelessly. You'd reach for debugging or the incident workflow during the event, and this once it's over and you're deciding what the organization learns from it.
Because the value of a postmortem isn't the document — it's whether the same failure is less likely next quarter. A draft that invents a cause, hardens a guessed timeline, or names a person teaches the wrong lesson and quietly makes people less willing to be candid the next time. One built from confirmed facts, honest about what's still unknown, and blameless about how the system failed is one a team will trust and act on. The model can assemble that draft quickly from your notes; which factors are real, which fix matters most, and whether the record is true enough to publish is the judgment that stays with the incident's owner.