A postmortem reading club is a regular, informal session where engineers read one past incident write-up and discuss what happened, what the lessons were and what changed. Pick a postmortem, send it ahead, and spend 30 minutes on questions. It spreads learning to people who were not in the incident.
Where the idea comes from
Google's SRE book lists postmortem reading clubs among the activities that reinforce a postmortem culture. Teams host regular sessions where an interesting or impactful postmortem is brought to the table for open dialogue with participants, non-participants and new joiners about what happened, what lessons the incident imparted and the aftermath. It notes that the postmortem reviewed is often months or years old. The Workbook adds that several Google offices run informal clubs open to all employees.
The same chapter makes the underlying point: the value of a postmortem is in the learning it creates. A postmortem nobody reads helps nobody.
Format you can copy
| Element | Suggestion |
|---|---|
| Frequency | Monthly is enough to start |
| Length | 30 minutes |
| Pre-read | One document, sent two days ahead |
| Facilitator | Rotates each session |
| Rule | No blame, and no "I would never have" |
| Output | One takeaway you will apply, noted in a shared page |
Google's book also suggests refreshments. It is a small thing that makes the meeting feel like a conversation, not an audit.
What to read
Rotate sources so the club does not become a review of your own team's failures:
- Your own old postmortems, especially ones where the actions finished long ago. Did the fix hold?
- Postmortems from other organizations that are published openly. Several large operators share them; PagerDuty's public guide lists examples from other companies as references.
- Security incident write-ups that include a timeline and causes. Our own pieces such as the SolarWinds timeline show the kind of document that works well.
When reading external write-ups, remember that you see only what the author chose to publish. Treat them as partial accounts.
Questions to ask in the session
- What did the responders know at each decision point? What did they not know?
- What made the failure possible? Was it a gap in design, process or tooling?
- What went well that we would want to copy?
- Where did the author get lucky?
- Could this happen here? What would our first signal be?
- What one change would we make this quarter?
Question five turns reading into action. If the answer is "yes, and we would not notice", log it as a finding.
Steps to start
- Ask two or three people to co-host.
- Choose the first postmortem. Make it a short, well written one.
- Set the calendar series for the next three months.
- Open the session by restating the blameless rule.
- Capture the takeaway in a shared page and review it at the next session.
- After three sessions, ask the group what to change. Google's book recommends surveying teams on whether the postmortem practice is helping.
How Safeguard fits
If a session uncovers questions about your own dependency exposure, you can start with an inventory. Safeguard's SBOM and dependency scanning supports that, with a free scan at https://gold.safeguard.sh/scan.
Quick check
Should the original incident commander attend?
It helps when they are willing, since they can answer questions. Do not make attendance mandatory or put them on the spot.
How many people is too many?
Smaller groups make discussion easier. Larger groups can split into tables.
Sources
- Google SRE book, Postmortem Culture
- Google Site Reliability Workbook, Postmortem Culture
- PagerDuty incident response documentation, postmortem process
Last reviewed: 19 October 2026.
