BoardSnap is an iOS app that reads whiteboard photos and produces clean summaries and action items in about ten seconds. This incident postmortem template structures a blameless review of what happened, why, what the impact was, and what changes will prevent recurrence — on a whiteboard that BoardSnap turns into the postmortem doc.
Run this within 48–72 hours of an incident being resolved — close enough that memory is fresh, far enough that the on-call team has slept. Don't run the postmortem while the incident is still active.
Every significant incident deserves a postmortem: outages, data loss events, security incidents, and deployments that caused user-facing degradation. The threshold is your call — but if an incident had paying customers affected for more than 30 minutes, it warrants a postmortem.
A chronological list of events from the first signal (alert, user report, or internal observation) to full recovery. Write times, not durations. 'At 14:32 UTC, alert fired.' Write the detection event, the investigation pivots, the mitigation steps, and the recovery. The timeline is the most objective section — stick to what happened, not why.
The technical condition that allowed the incident to occur. Not the person who made the change — the system condition that made the change impactful. A blameless postmortem names the root cause as a system problem, not a human error. Use the five whys if needed: ask 'why did this happen?' five times until you reach a systemic cause.
Users affected (number or percentage), duration of impact, services degraded, and business impact (support tickets, revenue, SLA breaches). Write specific numbers. 'Some users saw errors' is not impact analysis. '12% of users on iOS 17.4 experienced 503 errors for 47 minutes from 14:32 to 15:19 UTC' is impact analysis.
Detection time, escalation speed, communication to users, rollback success, or any part of the response that worked better than expected. Blameless postmortems credit the responders as well as holding the system accountable. What the team did well should be recognized and repeated.
The specific changes — technical, process, or monitoring — that will prevent this incident or reduce its impact. Each action has: a description, an owner, and a due date. No action item without an owner. This section is the entire point of the postmortem.
State it explicitly at the opening: 'This postmortem is blameless. We're here to improve the system, not to assign fault to individuals. Human error is expected in complex systems — our job is to find the system conditions that made the error impactful.' Say it every time.
Ask: 'Who was first paged?' Write the time and what they saw. Then: 'What happened next?' Move forward chronologically. Multiple people in the room will have different parts of the timeline — you need all of them.
Why did the service fail? Because a config change removed a rate limit. Why was the rate limit removed? Because the config template didn't include it by default. Why did the template not include it? Because the template was copied from a service where rate limiting is handled differently. Each 'why' gets you closer to the systemic cause.
Pull the numbers before the meeting: error rates, user impact counts, support volume spike, revenue impact. Write them on the board. Specific numbers are what make the postmortem actionable and what justify the investment in the follow-up actions.
For each follow-up action: write a name next to it and a due date. If the team can't agree on an owner, the action is aspirational, not real. P1 action items should have completion dates within two weeks.
BoardSnap reads the timeline, root cause, impact, what went well, and follow-up actions. The output is a structured postmortem document — the follow-up actions are the action items, the timeline is the chronology section, and the root cause is the key finding.
Writing a postmortem in a Google Doc produces a long narrative that fewer people read than you'd hope. Writing a postmortem on a whiteboard — with the whole incident response team physically present and contributing to the timeline — produces a shared understanding that survives the document.
BoardSnap converts the shared understanding into the document in ten seconds. The output is structured, dated, and ready to share with stakeholders. The follow-up actions are the action items — no reformatting required.
60–90 minutes for most incidents. Major incidents (multi-hour outages, data loss, security events) may require 120 minutes. Any postmortem that routinely exceeds 90 minutes is either covering too many incidents at once or not staying focused on the template structure.
Everyone who was part of the incident response — on-call engineers, their leads, and anyone from product or ops who made decisions during the incident. Managers who weren't in the incident response room should generally not attend — their presence changes the blameless dynamic.
Five whys is a root cause analysis method where you ask 'why did this happen?' and then ask 'why?' again about the answer — repeating five times until you reach a root cause that's systemic rather than symptomatic. It was developed by Sakichi Toyoda at Toyota and is standard practice in incident postmortems and manufacturing quality control.
The free tier includes one project and 30 boards. Pro is $9.99/month or $69.99/year for unlimited boards and AI chat on every postmortem board you snap.
Go deeper on the root cause with a dedicated five whys or fishbone diagram session.
Address the bug backlog that an incident often surfaces.
After a systemic incident, review the architecture to find structural vulnerabilities.
No exporting, no transcription. Snap the board, get the action plan.