A days since last incident counter rewards the absence of reports, not the absence of problems. Once a streak matters, people avoid declaring incidents to keep it alive. Track how fast issues are reported and learned from instead, and treat early reports as a good sign.
The problem with a streak
A streak counter has one way to improve: time passing without a declared incident. It says nothing about how many near misses happened, how many issues were found early, or how many went unnoticed.
The Google SRE book makes the underlying point in its chapter on postmortem culture. If a culture of finger pointing and shaming individuals or teams prevails, people will not bring issues to light for fear of punishment. A visible streak adds a team wide penalty to the same effect. Whoever declares an incident resets the number for everyone, and that person knows it.
The results are easy to predict:
- Borderline events get described as "just an alert" or "not customer facing".
- Reports are delayed until a weekend passes or a quarter ends.
- Declared incidents are downgraded in severity so they do not reset the count.
- Near misses go unrecorded, so nobody learns from them.
What to measure instead
The aim is more honest, earlier reporting, and faster learning. Some metrics that fit:
| Metric | What it tells you |
|---|---|
| Time from first signal to declared incident | Whether people raise problems quickly |
| Number of near misses reported | Whether the team feels safe describing them |
| Share of incidents with a written review | Whether learning happens |
| Follow up actions completed from reviews | Whether learning leads to change |
| Time to awareness of a newly published issue affecting you | How quickly you notice outside signals |
A rise in near miss reports can look bad on a dashboard. Read it the other way. It usually means the team trusts the process.
How to run reviews so reporting rises
The SRE guidance describes a blameless postmortem as one that focuses on contributing causes without indicting any individual or team, and that assumes everyone involved acted with good intentions on the information they had. It also says you cannot fix people, but you can fix systems and processes that support better choices.
Practical steps:
- Define review triggers before an incident, so declaring one is a rule, not a judgment against someone.
- Thank the reporter in the review, by name only if they agree.
- Track follow up actions to completion and publish the rate.
- Never use incident counts in individual reviews.
If you already have a counter
Do not tear it down in a day. Move it to a corner, add a second number beside it, such as near misses reported this month, and explain the change. Over a quarter, let the second number take over.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a newly published issue surfaces and how quickly you can see which of your projects it touches.
Safeguard's zero-day discovery and continuous monitoring can shorten the time to awareness for a new issue. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Is it wrong to celebrate time without an incident?
Celebrating is fine. Making the streak a goal that people feel they must protect is the problem. Pair it with reporting metrics.
How do we know near miss reports are rising for the right reason?
Look at whether time from first signal to declaration is falling and whether reviews produce completed actions. Both should improve together.
Sources
Last reviewed: 19 October 2026.
