AI Meeting Notes for Incident Reviews
Incident reviews are only as good as their timeline, and most timelines are rebuilt from memory days later. Here is how continuous work memory turns postmortem archaeology into retrieval.
The timeline is the part nobody defends
Incident review practice has two well-defended ideas. The first is blamelessness. The second is action-item discipline. Both get argued about in public, both have strong templates behind them, and most teams can tell you where they stand on each.
The third component gets almost no attention, and everything else rests on it. Google's SRE guidance describes a postmortem as a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root causes, and the follow-up actions to prevent recurrence. Impact, mitigation, and cause are all claims about sequence. They are only as trustworthy as the timeline underneath them.
That timeline is usually the least rigorous artifact in the whole process. It is assembled after the fact, from scrollback, from dashboards that have already rolled over, and from what four tired people remember about a two-hour window. Nobody defends it because nobody thinks of it as a deliverable. It is treated as the boring prerequisite to the interesting analysis.
Freshness is a constraint, not a virtue
The SRE workbook makes an observation that is easy to nod at and hard to operationalise: a prompt postmortem tends to be more accurate, because information is fresh in the contributors' minds. That is presented as an argument for speed, and it is. But read it the other way and it is a statement about decay.
If accuracy depends on freshness, then every hour between the incident and the write-up is quietly removing evidence. The review scheduled for Thursday because that was the first slot everyone could make is not neutral. It is a decision to run the analysis on a degraded record.
Most teams respond to this by trying to write faster. That works until the incident lands on a Friday, or during a launch, or on the week the person with the clearest picture is on leave. Speed is a real lever, but it is a lever against a clock that should not have been running in the first place.
What actually goes missing between the incident and the review
It is worth being specific about what decays, because it is not the big facts. The outage window, the error rate, the deploy that triggered it - those are in systems that keep records. Nobody forgets that the database fell over.
What goes missing is the reasoning. Why the first mitigation was tried before the obvious one. What the graph looked like at the moment someone decided it was a network problem. Which Slack thread contained the observation that turned out to be correct forty minutes before anyone acted on it. Who said the thing that everyone later agreed was the turning point, and what they were looking at when they said it.
This is exactly the material that separates a postmortem that changes something from one that documents something. A timeline of events tells you what happened. A timeline of decisions tells you why a competent team took the path it took, which is the only thing you can actually redesign around.
Archaeology versus retrieval
There are two ways to produce an incident timeline. The common one is archaeology: after the fact, someone digs through channels, calls, dashboards, and memory, and reconstructs a plausible sequence. It is slow, it is unevenly accurate, and its quality depends heavily on who happens to be doing the digging.
The other is retrieval. If the context was captured continuously while the work was happening - the calls, the screens people were actually looking at, the decisions as they were made - then building the timeline is a query rather than an excavation. The question changes from "what do we remember" to "what does the record show".
This is the practical case for treating work memory as infrastructure rather than as note-taking. Screens, meetings, decisions, and follow-ups captured as they happen are not more notes to read. They are the substrate that makes the incident review's central artifact reliable by default instead of by effort.
Designing capture for the incident hour
The incident hour has properties that make conventional capture fail. Nobody is going to take notes. The important calls are unscheduled, so a meeting bot invited to a calendar event is looking at the wrong place entirely. Half the signal is visual - a dashboard, a trace, a diff someone is scrolling through while talking.
Botless capture matters here for a reason beyond preference. An incident bridge that someone spins up in ninety seconds does not have a bot in it, and asking an incident commander to add one is asking for the wrong priority at the wrong moment. Capture that works without a meeting invitation is the only kind that survives the conditions incidents actually happen in.
Screen context matters for the same reason. "It looked fine on the dashboard" is a claim the review will want to evaluate, and it is only evaluable if there is a record of what the dashboard actually showed. That is the difference between a postmortem that can examine a judgment call and one that can only record its outcome.
A neutral record makes blamelessness easier, not harder
The instinctive objection to recording an incident is that it cuts against blameless culture. If everything is captured, does that not make it easier to point at the person who made the wrong call at 02:14?
The SRE guidance defines blamelessness as assuming everyone involved had good intentions and did the right thing with the information they had. That definition is worth reading carefully, because it is an evidentiary standard, not a manner. It asks what information a person actually had. Without a record, that question cannot be answered, and the conversation drifts toward what someone should have known - which is exactly where blame lives.
A good record moves the analysis toward the system, which is the stated goal: you cannot fix people, but you can fix the systems and processes that support them in making the right choices. "The alert fired but did not page" is a systems finding. "He missed the alert" is a blame finding. The first requires evidence. The second only requires a gap in the record and someone willing to fill it with an assumption.
Action items survive when they keep their context
The sharpest line in the SRE workbook is about follow-through: to users, a postmortem without subsequent action is indistinguishable from no postmortem. The workbook is equally direct about what makes action items fail - ambiguous phrasing like "improve" or "make better", and no clear owner.
Vagueness is usually a symptom rather than a cause. An action item written six days after the incident, by someone summarising a discussion they half-remember, is vague because the specificity has already been lost. The person writing it no longer knows precisely which alert, which threshold, or which runbook step was the problem, so they write something safe.
Action items that stay connected to the moment they came from keep their edges. The follow-up points back at the decision it came from, and the decision points back at what the person was looking at. Six weeks later, when someone asks whether this fix is still needed, the answer is retrievable instead of debatable.
How to evaluate this honestly
If you are considering a work-memory layer for incident practice, the useful questions are narrow. Does capture work for unscheduled calls, or only for calendar invitations? Does it retain what was on screen, or only what was said? Can you retrieve by decision and by time window, not just by keyword? Who can read an incident's record, and can that be scoped for a security or personnel-sensitive event?
The honest framing is also worth keeping. Better capture does not produce a better postmortem on its own. It removes one specific failure - the degraded timeline - which is upstream of several others. Blameless culture is still a leadership practice. Action tracking is still a discipline. Neither is a tooling outcome.
What changes is where the effort goes. Teams stop spending the first half of the review rebuilding what happened and start spending it on why the system allowed it. Prompt postmortems stop depending on everyone being available while memory is fresh. The recurring incident becomes visible as recurring, because the earlier one is still retrievable rather than filed and forgotten.
Sources
- Postmortem Culture: Learning from Failure - Google SRE Book
- Postmortem Culture - Google SRE Workbook
- Example Postmortem - Google SRE Book
- Incident Management Guide - Google SRE
FAQ
Does an AI notetaker replace the postmortem document?
No, and treating it that way is the main way this goes wrong. The postmortem is an analysis: impact, contributing causes, and owned follow-up actions. Captured context is the evidence the analysis draws on. A transcript is not a postmortem any more than a pile of logs is an explanation. The point is that the author starts from a reliable record instead of from reconstruction.
What should be captured during an incident versus during the review?
During the incident, capture should be passive and require nothing from responders: the calls that happen, the screens people are working from, and the decisions as they are made. During the review, the valuable capture is different - the reasoning about contributing causes, the disagreements, and the action items with their owners. The first makes the timeline accurate. The second makes the follow-up survivable.
Does recording everything undermine a blameless culture?
It depends on what the record is used for, which is a leadership question rather than a tooling one. Google's SRE guidance defines blamelessness as assuming people acted reasonably given the information they had. Establishing what information someone actually had requires evidence. A team that uses the record to examine systems will find it strengthens blamelessness; a team that uses it to identify culprits had a culture problem the record did not create.
What about incidents involving security or personnel-sensitive detail?
Access control has to be part of the design rather than an afterthought. Some incidents touch customer data, security posture, or individual conduct, and their records need tighter scoping than a routine latency regression. The practical requirement is that scoping is decided per incident and enforced by the system, so sensitivity is a property of the record rather than a matter of who remembers to be careful.