The Handoff From Incident to Postmortem

The incident is over. The graph is green, the responders are exhausted and relieved, and everyone wants to close the laptop and never think about it again. That completely understandable urge is where most of the learning from incidents quietly dies. The stretch between “resolved” and “postmortem written” is where context is freshest and where it evaporates fastest — and if you don’t manage the handoff deliberately, the outage that just cost you an hour teaches you nothing.

The handoff from incident to postmortem is its own small process, distinct from both running the incident and writing the retro. Do it well in the first few minutes after resolution and the postmortem almost writes itself later. Skip it and someone reconstructs a fuzzy story from memory a week on, if the postmortem happens at all. Here’s how to close an incident so the lessons survive.

Resolution is not the end of the incident

The most common mistake is treating “impact stopped” as “incident over.” It isn’t. A resolved incident still has a live tail: the timeline needs to be captured while it’s fresh, the follow-up needs an owner, and the responders need a clean release. An incident that just fizzles out — the channel goes quiet, everyone drifts off — leaves the postmortem unowned and the action items unspoken. The handoff is the deliberate act of converting a response into follow-up work before the context is gone.

Close the incident cleanly first

Before you hand anything off, actually close the incident, and do it explicitly. Don’t declare resolution the instant the graph recovers — confirm the fix held long enough to trust and that customer impact is genuinely gone. Then state it plainly in the channel:

🟢 INCIDENT RESOLVED — [short name]
Resolved as of: [time] (impact [start]–[end], ~[x] min)
What resolved it: [one-line, factual]
Confirmed holding: yes, [x] min stable
Standing down. Thank you all.
Postmortem owner: [name] — draft by [date]
Final severity: SEVx (started SEVy)

That message does four things at once: it releases the responders (they’re off the hook), it tells stakeholders it’s genuinely over, it names the postmortem owner, and it sets a due date. The postmortem-owner line is the hinge of the whole handoff — an incident that closes without naming who owns the follow-up is an incident whose postmortem quietly never happens.

Capture the raw material while it’s warm

The single highest-value thing you can do in the ten minutes after resolution is snapshot the context while it’s still in everyone’s heads. Memory degrades fast, and by tomorrow the precise sequence and the “why we did that” will be gone. Grab it now:

POST-RESOLUTION CAPTURE (do within ~10 min, while fresh)

[ ] Snapshot / export the incident channel (your raw timeline).
[ ] Confirm the timeline's key timestamps (detect, mitigate,
    recover) while people can still verify them.
[ ] Jot the open questions nobody had time to answer live
    ("why did this pass CI?", "why 13 min to mitigate?").
[ ] Note what people TRIED, including dead ends.
[ ] Capture immediate follow-ups already obvious to responders.
[ ] Preserve relevant graphs/logs before they roll off retention.

That last one bites teams constantly: the logs and metrics that explain the incident age out of short retention windows, and a postmortem written a week later finds the evidence already gone. Export or link the key graphs now, while they still exist.

The warm handoff to the postmortem owner

If the postmortem owner isn’t the incident commander, do an actual handoff conversation — brief, while it’s fresh — rather than dropping a link and vanishing. Five minutes of “here’s what happened, here’s what’s still open, here’s where the timeline and the graphs are” saves the owner hours of reconstruction and prevents the postmortem from missing the things only the responders know. A handoff template:

INCIDENT → POSTMORTEM HANDOFF
To: [postmortem owner]

The incident: [2-3 lines — what broke, impact, how resolved]
Timeline: [link to exported channel / draft timeline]
Evidence: [links to key graphs, logs, deploys — before they expire]
Still open (for you to dig into):
  - [question 1]
  - [question 2]
Obvious action items already surfaced:
  - [item]
Responders to interview: [names of who did what]
Target: blameless postmortem draft by [date]

Set the frame: blameless, and soon

Two things about the postmortem should be established at handoff. First, it’s blameless — the goal is understanding the systemic contributing factors, not finding who to blame. Naming that up front, at the moment of handoff, sets the tone before anyone gets defensive. Second, it should happen soon, while memory is warm — a postmortem written a month later is a postmortem written from evidence that’s half-gone and recollections that have reshaped themselves around the outcome. Give it a real due date, not “when we get to it.”

Common mistakes

The fizzle. The channel goes quiet and the incident never formally closes, so the postmortem is unowned. Close explicitly and name an owner.
No named owner. “Someone should write this up” means nobody does. Assign a specific person and a date at close.
Losing the evidence. Logs and graphs age out before the postmortem is written. Snapshot them within minutes of resolving.
Cold handoff. Dropping a link with no context forces the owner to reconstruct everything. Do a warm, five-minute handoff.
Waiting too long. Days or weeks later, memory is reshaped and detail is gone. Do it while it’s warm.
Skipping small incidents. “It was minor, no postmortem needed” — but minor incidents often reveal cheap systemic fixes. At least capture the lightweight version.

Where AI bridges incident to postmortem

This handoff is one of the most valuable places to use AI, because the raw material — a messy channel scrollback — is exactly what models turn into structure well, and a human is right there to verify it while context is fresh. At resolution, feed the incident channel to a model and have it draft the timeline and a first postmortem skeleton: what happened, the timeline, the impact, the open questions, and candidate action items. That draft is a starting point the responders correct while their memory is still sharp — not the final artifact. It dramatically lowers the activation energy of the postmortem (a mostly-drafted doc is far easier to finish than a blank one), which is often the difference between a postmortem that gets written and one that doesn’t. Keep it blameless and human-owned: the model drafts, the people who lived the incident verify and add the judgment. The Incident Response tool can turn the resolved incident’s context into exactly this structured handoff draft.

Wrapping up

The minutes right after “resolved” are when the learning is most available and most fragile. Close the incident explicitly, name a postmortem owner and a date, snapshot the timeline and evidence before they fade or expire, and do a warm handoff to whoever’s writing it up — framed as blameless and soon. That small, deliberate process is what turns an expensive outage into an actual improvement instead of a story people half-remember. Don’t let the relief of “it’s fixed” cost you the lesson you just paid for.

AI-drafted timelines and postmortem skeletons are starting points. The people who ran the incident own the final, blameless record.