Send a short weekly report listing the past seven days of incidents with a one line summary, impact, status and a link to the postmortem, to as wide an audience as possible. Once a quarter, pull the most useful ones into a greatest hits note. Learning only happens if people see the incidents.
The practice
Google's Workbook recommends reporting incidents and outages weekly: create a report containing the incidents from the past seven days, share it as widely as possible, and from the weekly reports compile a periodic greatest hits report. The SRE book describes related habits, including a monthly newsletter that features an interesting, well written postmortem, and posting new postmortems to internal channels.
The Workbook also advises announcing a postmortem draft on internal channels, and sharing a recent postmortem of interest at a company all-hands.
A template for the weekly note
| Field | Content |
|---|---|
| Incident | Short plain name |
| Date and duration | UTC |
| Impact | Who or what was affected, in a sentence |
| Cause in one line | Current best understanding, marked draft if open |
| Status | Open, in review, actions in progress, closed |
| Link | Postmortem or ticket |
| One thing to learn | A single sentence anyone can use |
Keep the entire email to a page. The last field is the one people remember.
Rules that keep it safe to send widely
- No personal data. Google states that even its internal postmortems never include information that identifies an end user. Do the same.
- No names of individuals in cause lines. Use roles.
- Label unknowns. Say "cause under investigation" instead of guessing.
- Check legal sensitivity first. If an incident may involve notification duties, agree the wording with the right people before it circulates. See pre-incident legal readiness.
Steps to start this week
- Choose a day and an owner, such as an engineering manager or security lead.
- Create a simple list of last week's incidents from your ticket system.
- Fill in the template. If there were none, say so and link to a near miss or a good catch. See near-miss reports are free incidents.
- Send to an all-engineering list and post in a shared channel.
- After six weeks, ask readers what they use and what to drop. Google surveys its teams on whether the practice supports them.
- Every quarter, write the greatest hits: the incidents that taught the most, grouped by theme.
Why it works, and where it fails
Wide sharing builds a norm that incidents are normal and learning is expected. It fails when the report becomes a scoreboard that teams fear. Present it as information, not ranking. If the tone turns into a league table, expect fewer incidents to be declared, which defeats the purpose. The Workbook describes disengagement from the postmortem process as a sign that culture is failing, and suggests sharing high quality examples and reviewing high visibility postmortems for blameful language.
How Safeguard fits
For supply chain themes in your greatest hits, an inventory helps you check whether an old lesson still applies today. Safeguard's SBOM and dependency scanning is one way to do that, with a free scan at https://gold.safeguard.sh/scan.
Quick check
Should customers see the weekly report?
No. It is an internal note. Customer facing summaries need separate wording and approval.
What if nothing happened this week?
Say so, and share a near miss or an older lesson. A quiet report keeps the habit alive.
Sources
Last reviewed: 19 October 2026.
