Invite the incident commander, the owners of the affected systems, the key responders, and the engineering and product managers who can commit time to fixes. Add a customer liaison for the most serious incidents. Keep the meeting short, with the draft read beforehand, and share the notes with everyone else.
The core list
PagerDuty's public postmortem process names who it always invites:
- The incident commander, and a shadow if there was one
- Service owners involved in the incident
- Key engineers and responders
- The engineering manager for the impacted systems
- The product manager for the impacted systems
A customer liaison is optional and used for the top severity only. The same guide says these meetings generally last 15 to 30 minutes and are a wrap up, not the place to start the investigation.
Why managers are in the room
If the people who can say yes to the work are absent, you get a list of good ideas and no commitment. Atlassian's handbook builds this into its process: approvers from delivery and operations management sign off postmortems, and they are expected to prioritise the follow-up actions. Managers do not need to speak much. They need to hear the facts first hand.
Who is optional, and who to leave out
| Person | Attend? | Why |
|---|---|---|
| Incident commander | Yes | Keeps discussion on track |
| Responders who touched the systems | Yes | They hold the facts |
| System owners | Yes | They will own the fixes |
| Engineering and product managers | Yes | They can commit time |
| Legal or privacy | Sometimes | When data exposure or notification is involved |
| Support or customer liaison | Sometimes | When customers were affected |
| Executives | Optional | Useful to hear, but avoid an audience effect |
| Anyone looking for who to blame | No | Defeats the purpose |
Google's SRE book notes that senior management's active participation helps build a postmortem culture. Their presence works when they model the right behaviour, such as asking what information was missing, and backfires when they ask who should have known better. The Workbook has a short example of a leader slipping into blame and a colleague steering the conversation back to warning signs and why they were missed.
A simple agenda
Atlassian suggests this order, which fits a short meeting:
- Remind everyone the review is blameless, and why.
- Confirm the timeline.
- Confirm the causes.
- Generate actions by asking what could prevent this class of incident.
- Ask what went well, what could have gone better, and where we got lucky.
For an extended walk through, see run a post-incident review meeting without blame.
Mistakes to avoid
- Inviting the whole company. Share the document widely instead. A meeting with thirty people becomes a presentation.
- Reading the document aloud. Send it a day ahead and spend the meeting on disagreements.
- Leaving out the quiet responder. The person who noticed something odd and said nothing often has the most useful detail. Ask them directly, and in private first if needed.
How Safeguard fits
For incidents that start in a dependency or build, the meeting runs faster if you can show where the affected component lived. Safeguard's SBOM and dependency scanning supports that, with a free scan at https://gold.safeguard.sh/scan.
Quick check
Should the person who made the change attend?
Yes, as a source of facts. Make clear beforehand that the review looks at systems, not at them.
How long should the meeting be?
One published guide uses 15 to 30 minutes when the draft has been reviewed in advance. Complex incidents may need more.
Sources
- PagerDuty incident response documentation, postmortem process
- Atlassian incident management handbook, postmortems
- Google SRE book, Postmortem Culture
- Google Site Reliability Workbook, Postmortem Culture
Last reviewed: 19 October 2026.
