BriefMe
Sign in

Incident postmortem agenda template (60 minutes)

Incident postmortems go wrong when people fear blame and clam up. This shape starts by establishing ground rules for blameless analysis, builds a factual timeline first, then explores contributing factors before anyone jumps to solutions. A team that feels safe tells the truth.

Topic Minutes Running total
Ground rules State the rule: no individual blame, only systemic factors. Everyone gets heard. Learning, not punishment. 5 5
Timeline Build the factual sequence: when page went down, when alerts fired, when oncall was paged, root cause identified. 15 20
Contributing factors Why did the timeline unfold that way? Look for systems, processes, assumptions, and constraints. Not who made a mistake. 20 40
Action items Two or three changes to systems or runbooks so this class of incident is harder next time. Owner and date for each. 15 55
Close Confirm the actions, say when this retro closes out, and thank the team for the honesty. 5 60

Opens a working agenda you can start straight away. Nothing to sign up for — anonymous agendas are kept for 7 days.

Build it with your assistant

Already connected to BriefMe? Paste this. Connect BriefMe to Claude 

Using BriefMe, create a 60-minute incident postmortem for eight people: a 5-minute ground rules opening, 15 minutes for timeline, 20 minutes for contributing factors, 15 minutes for action items, and a 5-minute close.

Questions

How long should an incident postmortem be?
An hour is the baseline, scheduled within a day or two of the incident closing so details are fresh. A major incident merits ninety minutes so you can explore contributing factors without rushing. Never wait more than two weeks or memories blur and people start filling gaps with speculation. If the incident is still open, hold the postmortem after it closes, not during, so you have the full timeline.
Why is blameless so important?
Because people tell the truth only when they feel safe. A postmortem that opens by naming a person guarantees defensive responses and silence; the oncall will downplay their actions, others will minimize involvement, and you will hear a surface-level report instead of the real chain of decisions. Learning is always about systems, constraints, or communication gaps; blameless framing uncovers those patterns so the team can fix them before the next incident.
Who should run the postmortem?
Someone outside the team that had the incident, so they ask clarifying questions instead of defending the response. An engineering lead from another team works well; a peer from the same squad can work if the incident was not someone's mistake but a system failure. The key is that the facilitator has no stake in the outcome. If no one external is available, have two people run it together so one can stay neutral when the other is emotionally invested.

Related templates