A postmortem's lessons section has three parts: what went well, what went poorly, and where we got lucky. The lucky list matters most, because it records the defenses you did not have but did not need this time. Each luck item should become an action, or a deliberate decision to accept the risk.
Where the three headings come from
Google's example postmortems, in both the SRE book and the Workbook, use the same lessons headings: things that went well, things that went poorly, and where we got lucky. Atlassian's meeting agenda asks the same three questions: what went well, what could have gone better, and where did we get lucky.
The structure works because it separates three kinds of learning. One keeps good habits, one finds gaps, and one reveals risk that stayed hidden because nothing bad happened to land on it.
What goes in each section
| Section | What to write | Example in a security incident |
|---|---|---|
| Went well | Practices and controls that helped, so you protect them | The on-call engineer revoked the credential within minutes because the runbook was current |
| Went poorly | Gaps in detection, tooling, communication or process | The alert went to a channel nobody watched |
| Got lucky | Things that could easily have made it worse | The attacker's token expired before the second job ran |
In the Google example, the "went well" items are specific systems and behaviours, such as an automatic mitigation and a quick, cross-team response. They are not praise for individuals. The "poorly" items name missing sanity checks and missing rate limits, not people.
Why luck deserves its own heading
Luck is invisible in most reviews. If you only ask what failed, an incident that was contained by accident looks like a success. In the Workbook's bad example, the "got lucky" entry is an exclamation of disbelief. That is the wrong tone, but the right instinct: something unplanned saved the day, and it should be written up calmly with facts.
Security examples of luck:
- The secret was exposed, but the repository was private for the one day it mattered.
- A malicious package version was published, but your lockfile pinned an earlier version.
- The attacker had access, but the data they reached was stale.
Each of those is a control you may want to build deliberately, so you are not depending on chance next time.
How to fill it in as a group
- After confirming the timeline, ask: "What do we want to keep doing?" Capture two to four items.
- Ask: "What slowed us down or hid the problem?" Capture gaps.
- Ask: "What nearly went worse, and why didn't it?" Wait through the silence. This is the hard question.
- For each luck item, decide: build it, monitor it, or accept it. Record which.
- Move chosen items into your action list with owners.
For the wider meeting, see run a post-incident review meeting without blame. For events where nothing actually happened, see near-miss reports are free incidents.
Mistakes to avoid
- Using "went well" for individual praise. Recognition is good, but this section should name practices others can copy.
- Skipping luck because it feels like tempting fate. The point is to stop relying on it.
- Writing luck in dramatic language. State the fact and the risk.
How Safeguard fits
When a dependency is involved, reachability analysis can show whether a vulnerable function was actually called, which helps separate real exposure from luck. Safeguard offers it alongside SBOM and dependency scanning, and a free scan is available at https://gold.safeguard.sh/scan.
Quick check
Is a lucky escape a failure?
It is a risk that was not controlled. Treat it as a finding, and decide whether to build a control, monitor it or accept it.
Do all postmortems need all three sections?
Short ones can keep them to a line each. Skipping the luck section is the most common and costly omission.
Sources
- Google SRE book, Example Postmortem
- Google Site Reliability Workbook, Postmortem Culture
- Atlassian incident management handbook, postmortems
Last reviewed: 19 October 2026.
