Why this matters
A postmortem is a meeting and a document. The goal is to change how the system works, not to grade how people performed. The people closest to an outage hold details nobody else has: which dashboard they opened, what the error said, why they waited before escalating. That detail vanishes the moment someone starts worrying about blame.
Blameless means the write-up describes actions and conditions, not character. "The deploy failed and nobody noticed because the health check only tested a static page" is something you can fix. "Sam skipped testing" ends the conversation. Keep names in the timeline, because you need to know who did what and when, and keep the judgment out of it.
Two outputs make the hour worthwhile: a timeline that shows how the incident actually unfolded, and a short list of actions with owners that get closed. Format and tone can vary. Those two cannot.
Before you start
Write down which incidents get a review before you need the rule. A workable line is any incident that paged someone outside working hours, broke a customer-facing feature, lost data, or came close to any of those. Small ones can get a shorter document and no meeting. Deciding in the moment invites arguments about severity instead of fixes.
Pick a facilitator who was not the incident commander. Their job is to keep the discussion moving and to catch blaming language early. Add a scribe, or record the session with everyone's agreement and write it up after. Nobody should take notes and talk at the same time.
Hold the meeting within three working days. Memory fades fast, and after a week people reconstruct what they think happened rather than what they remember. Send a skeleton document ahead: a timeline table with a UTC timestamp column, an impact section, a contributing factors section, and an actions table with owner and due date. Ask attendees to add their own timestamps and links to queries, dashboards and chat threads before the meeting.
Gather the raw material yourself first. Pull alert history, deploy logs, the incident channel transcript and any config changes from the hours before. Put every timestamp in one timezone so the timeline does not restart at each entry.
How to do it
Run it in three moves: build the timeline together, ask what made each event possible, then turn that into actions. Let the timeline take the first half of the meeting. Keep the whole thing to 45 or 60 minutes unless customers were down for hours.
Watch your phrasing. "Why did you" puts people on the defensive. "What did you see at that point" and "what made that the obvious next step" get you the detail you need. The facilitator should use those questions in the first five minutes so everyone else copies the habit.
- State the ground rules out loud. Open with two sentences: we are here to fix the system, not the person, and anyone who says "I should have" gets asked what the tooling showed them instead. Say it every time, even when the room already knows.
- Build the timeline from artifacts first. Fill the table from logs, alerts, deploy records and chat before asking anyone to remember. Then add the human rows: what each person checked, what they expected, what they saw.
- Separate the trigger from contributing factors. The trigger is the change or event that started it. Contributing factors are the conditions that turned a small trigger into an outage, such as a missing alert or a runbook pointing at an old hostname. Expect more than one.
- Ask why the action looked reasonable. For each human decision, ask what was visible at that moment and what the person expected to happen. This usually turns up a real gap, like a misleading metric or a stale status page, so record it as a gap in the system with the evidence.
- Treat human error as a question. When someone says human error, ask what made the mistake easy. Two fields that look alike, a command with no dry run, an alert with two meanings. Fix the thing that made it easy and the same mistake gets much rarer.
- Write actions with an owner, a verb and a date. One name, one concrete change, one date. "Improve monitoring" will not survive review. "Add a p95 latency alert on the checkout API, owner named in the meeting, due 14 March" will. Split anything that needs two people.
- Cut the list to what will ship. Cap it at five and rank them. A long list nobody closes is worse than three fixes that land. Anything dropped gets a line in the document with the reason, so it is not re-argued next quarter.
- Have someone outside the room read it. If they cannot follow the timeline without asking a question, rewrite the timeline. Publish the document where the team already reads things and link it from the incident ticket.
How to check it worked
Check the actions, not the document. A clean write-up with no merged changes did nothing. Review the action list on the due dates and mark each item done, dropped with a reason, or overdue with a new date. Put that review in a recurring slot so it does not depend on someone remembering.
Watch for repeats. If the same service fails the same way twice, either the first review missed a factor or its action never shipped. That is information about the process, not about a person.
Read the tone of the next few write-ups. Teams that trust the process describe their own missteps in detail, including the wrong dashboard they stared at for ten minutes. Documents that stay vague and passive usually mean people still expect blame. Ask one attendee privately how the meeting felt, and take the answer seriously.
Measure your own response: time until someone knew, time until the cause was clear, time until customers recovered. Compare your numbers across incidents and see whether a fix moved them. There is no external target worth chasing.
Mistakes to avoid
Turning the meeting into a trial. If a manager opens with "walk us through exactly what you did", the room goes quiet. The facilitator states the frame first and interrupts blame politely, every time, including from senior people.
Stopping at a single root cause. Most incidents come from a chain of small conditions. One cause produces one fix, and the next incident finds the conditions you skipped.
Vague actions with no owner. "Add better alerts" sits in a backlog for a year. If you cannot name the person and the change, the meeting is not finished.
Skipping near misses because nothing broke. They cost little to review and often expose the same weak alert that will hurt later. Reviewing them also builds the habit before a bad night.
Some factors keep coming back: alerts that never fired, a rollback nobody has practiced, a release process that lives in one person's head. If that is your pattern, fixing the platform rules out a whole class of contributing factors before the next review. Cloudverg's Delivery platform setup is one option, a fixed price engagement at $14,500 over four weeks that covers pipelines, monitoring and alerting, and a tested rollback. Doing the same work in house works too, if your team has the weeks to spare.
Frequently asked questions
What does blameless mean in a postmortem?
It means the document and the meeting describe actions, conditions and tooling, not people's character. Nobody gets graded on the incident. You still record who did what, because the timeline needs it, but the question is always what made that action look reasonable at the time.
Who should attend an incident postmortem?
The people who touched the incident: whoever was on call, the person who found the cause, whoever made the change that triggered it, and the service owner. Bring one person from a neighboring team if they were paged or affected. Keep it small enough that everyone can speak, then share the notes with everyone else.
How soon after an incident should you hold the review?
Within three working days, and sooner for anything serious. The document can start the same day using timestamps from logs and chat. The meeting needs people, not polish, so do not wait for a perfect write-up.