The incident is closed, the channel archived, and the postmortem draft is already written — not by the responder, but by a model that read the timeline, the Slack conversation and the investigation data. That is how it works at incident.io: the template decides which sections the AI handles, and the document moves through In progress → In review → Completed.
The vendor layer underneath is in motion. Jeli reaches end of life on 22 December 2026, and incident analysis moves into Post-Incident Reviews inside the PagerDuty web UI — still in Early Access. FireHydrant was acquired by Freshworks and is folding into their ServiceOps. The template will outlive this reshuffle, and it is the template that decides what the agent gets and what a human still has to write.
Fields split into two classes
Part of a postmortem is derivable from systems. The timeline assembles itself from alerts, deploys and channel messages. Detection comes from when the alert fired. Impact is computed from metrics and the status page. Resolution is visible in the action that stopped the degradation. A model extracts all of this without human help, and more carefully than a responder who has been awake since 3 a.m.
The other part is derivable from nowhere. Why the decision looked right at the time. What information the person had when they made it. What almost went worse, and did not.
| Field | Where it comes from | Who fills it in |
|---|---|---|
| Timeline, Detection, Impact, Resolution | alerts, deploys, metrics, channel | agent |
| Root Causes, Trigger | hypotheses plus confirmation in data | human, agent assists |
| Where we got lucky, Lessons Learned | the participant's head | human only |
| Action Items | a team decision | human only |
An engineer's value in a postmortem has moved to the bottom of this table. The top rows automate, the bottom ones do not, and they are what makes the document useful six months later.
The two fields teams lose most often
The popular "five questions" frame — what happened, why, what was the impact, how did we respond, how will we prevent recurrence — is three fields shorter than the canonical template in the SRE Book. Two of them are worth bringing back.
Trigger separate from Root Causes. The trigger is what set it off ("deploy v2.3.0 at 14:18"). The cause is why the system was vulnerable to it ("a migration without an index passes review because the DB change checklist is not used in this repo"). Merge them into one field and you get a corpus where incidents match on the trigger and diverge on the mechanism. Searching for similar cases — by agent or by eye — starts returning noise.
Where we got lucky. The only place that records risks which did not fire this time: the table was nearly empty, the incident landed in daytime traffic, the second region was missed by chance. These are not observable events — nobody can write them down except a participant. One line here is usually worth three bullets from Lessons Learned.
The skeleton
Date / Authors / Status — metadata, set by the system
Summary — 3-5 lines for those who missed the channel
Impact — users, minutes, money
Root Causes — why the system was vulnerable
Trigger — what set it off, as its own field
Resolution — what stopped the degradation
Detection — how we found out, and after how long
Action Items — owner + deadline, one per line
Lessons Learned
What went well
What went wrong
Where we got lucky — do not skip
Timeline — UTC, facts without interpretation
Supporting information — graphs, queries, links to PRsThirteen sections for a SEV3 look excessive — half of them close with a single line. An empty heading is more honest than a missing one: it shows the question was asked.
When a postmortem is mandatory
The canon states triggers as thresholds rather than a severity scale: user-visible downtime or degradation beyond a threshold, data loss of any kind, on-call intervention such as a release rollback or traffic rerouting, resolution time above a threshold, a monitoring failure. Plus the right of any stakeholder to request a review.
The "SEV1/SEV2 — mandatory" matrix is a local layer on top of that list, workable when severity is already set by strict criteria rather than the responder's gut feeling. A threshold on burned error budget goes into the same matrix — the number comes from your policy, the canon does not set it.
Where action items die
An item without a human owner and a date is not an action, it is a phrasing of regret. A team cannot be the owner: with several people accountable, nobody is. Auto-creating tickets from the template removes the one step where postmortems break off — moving decisions into the tracker.
A separate signal is repeated reviews of the same class. Three postmortems with the same cause mean the problem is not knowledge but missing automation, and from there it counts as toil.
What does not automate
A model reproduces the markup, assembles the chronology and proposes a phrasing for the cause. It does not create the conditions in which a person writes "I did not understand the alert" instead of "the alert was unclear".
Blameless has a machine consequence too. "Bob deleted the table" gives an agent nothing: a name is not a feature. "The system allowed the table to be dropped with one command and no confirmation" describes a mechanism, and the next case like it can be found by that description. A blaming postmortem is bad for the culture and useless as data.