Write for a reader who was not there. Add a short background and glossary, give impact as numbers or a reasoned estimate, describe recovery step by step, and publish the document to the widest audience that could benefit. A postmortem full of team jargon teaches only the team.
Why audience matters
Google's Workbook says the value of a postmortem is proportional to the learning it creates, and that the document should by default be accessible to everyone at the company. It lists failure modes in a deliberately poor example: missing context (terms specific to one team, with empty background and glossary sections), omitted details (only a duration, no size of impact), an empty recovery section, and a limited audience. It also notes that delayed publication loses detail.
Five habits
1. Define terms once. Use the Background and Glossary sections, linking to longer documents if needed. The Workbook specifically advises this for team specific terminology.
2. Quantify impact. Even a well informed estimate beats nothing, according to the Workbook, because if you cannot measure it you cannot know it is fixed. Say how you estimated.
3. Show the mechanism. Explain the trigger and the underlying causes at a lower level, not just a summary. Readers from other teams learn from mechanisms they can recognise in their own systems.
4. Describe recovery. What was done, in order, and what slowed it down. This is often where the most reusable lessons sit.
5. Share widely. Announce it on internal channels, and consider whether a customer facing version makes sense. Google says a thoughtful, honest postmortem is also a key tool in restoring shaken trust.
An outline for outsiders
| Section | Reader's question |
|---|---|
| Summary | What happened, in three sentences? |
| Background and glossary | What do I need to know first? |
| Impact | Who was affected, how much, how long? |
| Timeline | What happened in what order? |
| Causes and trigger | Why did it happen? |
| Recovery | How did we get out? |
| Lessons | What went well, poorly, and where were we lucky? |
| Actions | What changes, who owns it, by when? |
For a template version, see blameless postmortem template.
Security specific cautions
- Remove personal data. Google's internal postmortems never include information that identifies an end user.
- Keep exploit detail at the level readers need. Internal readers rarely need working attack steps.
- Check with legal before wide circulation if notification duties may apply.
- Use consistent time zones so cross team readers can line up their own logs. See UTC and clock sync for incident timelines.
Test with one outsider
Before publishing, ask someone from another team to read it and tell you what confused them. Fix those spots. This costs ten minutes and catches most missing context.
How Safeguard fits
For incidents involving software components, Safeguard's SBOM and dependency scanning can supply the inventory facts that make the impact section concrete. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Should every postmortem be company wide?
By default yes, with sensitive details removed. Restrict only what legal or security reasons require.
Is an estimate acceptable for impact?
Yes, if you label it as an estimate and explain the basis. It is better than leaving impact blank.
Sources
Last reviewed: 19 October 2026.
