How to run a remote postmortem
A postmortem is the meeting after an incident where the team works out what happened, why, and what changes so it does not happen the same way again. On a remote team it often becomes an hour-long call where people rebuild the timeline from memory, and a doc of action items nobody opens again.
Run it from writing instead. Build the timeline from the incident channel, review it together for a short block in an open voice room, and leave with follow-ups that each have one owner and a date.
The usual way
A remote postmortem often looks like this.
- The memory call. Everyone is on video, trying to agree on what time the alert fired and who saw it first.
- The blank doc. Someone shares a template with empty headings and the meeting is spent filling them in live.
- The blame drift. Without a written record to point at, the talk drifts to who should have caught it.
- The orphan action items. Ten bullets at the bottom of the doc, no owners, no dates. A month later the same thing breaks.
A format for a distributed team
1. Write the timeline before anyone meets
The person running the postmortem drafts the timeline from the incident channel, not from memory. Each line is a time, what happened, and a link to the message that shows it.
- 14:02 Error rate alert fires in the incident channel
- 14:09 First responder confirms checkout is failing
- 14:31 Config change rolled back
- 14:40 Error rate back to normal
Post the draft in a thread in the team channel a day ahead. People correct it in the thread, with links. By the time anyone meets, the facts are settled.
2. Ask three questions, in writing first
Under the timeline, post three questions and let people answer in the thread before the review.
- What went well? The parts worth keeping next time.
- Where did we lose time? Specific moments from the timeline, not people.
- What would have caught it sooner? A check, an alert, a test, a step in a runbook.
Written answers give the quiet people and the people in other time zones the same say as whoever talks first on a call.
3. Keep the live review short
Meet for a short, fixed block. Talk in a walk-in voice room beside the channel instead of booking a call. The room is open, so whoever has context walks in, and someone who only needs the outcome reads the thread later.
The review has one job: turn the written answers into a short list of changes. The timeline is already agreed, so nobody spends the block on what time the alert fired.
4. Every follow-up gets one owner and one date
Post each follow-up as its own reply in the thread.
- Change: Add an alert on checkout error rate per region
- Owner: one person, by name
- Date: the day it should be done
One owner, not a team. A follow-up owned by "infra" is owned by nobody.
5. Keep it blameless on the page
Write about systems and steps, not people. "The rollback took 22 minutes because the runbook pointed at the old dashboard" leads to a fix. "The on-call engineer was slow" leads to a quieter team at the next incident.
Make it repeatable
- Pin the format. The next postmortem starts from the last one's thread.
- Log the decisions. "We will not add a second approval step" is a decision too. Record it with the reason using the format in How to keep a decision log in team chat.
- Link it from the incident. Reply in the incident channel with a link to the postmortem thread, so anyone reading the incident later finds what changed. How to run an incident war room for a remote team covers the incident itself.
- Check the follow-ups. Close each one by replying in its thread with a link to the change.
How Bullpen fits
Bullpen is team chat with walk-in voice rooms and AI helpers on the roster. A postmortem can live in one thread from the first draft of the timeline to the last closed follow-up.
The timeline comes from the record. The incident already happened in a channel, so every line of the timeline can link to the message it came from.
The review happens in the channel's walk-in voice room. It stays open beside the channel. People walk in for the review and leave when it is done.
Wren writes the notes. Wren is an AI helper. In that walk-in voice room, Wren posts notes and action items back to the channel the room belongs to, so what was agreed out loud lands in writing.
Scout helps build the timeline. Scout is an AI helper on the same roster. Mention Scout and ask when the rollback started. Scout answers from what was said and links the message it came from.
Nix keeps the follow-ups moving. When an owner commits to a date, mention Nix in that follow-up's thread and the reminder arrives in the channel on the day. How to keep track of follow-ups in team chat covers the details.
Try it after your next incident
Before anyone books a call, draft the timeline from the incident channel and post it in a thread with the three questions above.