Near-Miss Report

A platform reports incident count down 40% year on year and presents it as progress. Three facts make that number unreliable: the organisation reporting it also sets the definition of "incident", declaring one costs an engineer a postmortem and leadership attention, and failures with no error signal were never counted at all.

Every one of those pushes the count down without anything improving. A near-miss report is the counterweight. It records the deploy that was caught by a canary, the certificate noticed three days before expiry, the script whose dry-run output was wrong, the alert that fired for a condition that would have become an outage in another hour. It is the one reliability number that rises when the culture gets healthier, which makes it impossible to improve by saying less.

Why it matters

Most reliability metrics are measures of harm, so the way to improve them is either to reduce harm or to reduce reporting. Teams under pressure do some of both, and no metric built on harm can tell the two apart. A near-miss count breaks the ambiguity: it can only go up by people writing things down.

It is also the earliest available signal. A near miss is the same causal chain as an incident with one link intact, so the conditions it describes are the conditions of the next outage. The chain is observable weeks before anyone is paged, at a point where the fix is cheap and nobody is under pressure.

And it is the cheapest possible source of learning. A near miss has no customer impact, no escalation, no credits and no blame dynamics, so the account people give of it is more honest than the account they give of an incident.

Implementation patterns

• Make the bar explicit and low: anything that would have caused customer impact if one further thing had gone wrong, or if it had been noticed an hour later.
• Keep the artefact small. A few sentences: what nearly happened, what stopped it, what would have happened if it had not, and one proposed change. A near miss that requires a full postmortem template will not be filed, and the filing is the whole value.
• Report the count as a positive in the same review as the incident count. If only harm is reported upward, the safe way to look good is to say less.
• Separate the trend from the level. The absolute number depends on how the bar is drawn; a count falling while incidents hold steady is the finding, because it means reporting is drying up.
• Close the loop visibly. Publish what changed because of a report; nothing suppresses reporting faster than filing into a void.
• Pair it with the time-to-detect distribution. Rising detection times and falling near-miss counts is the signature of a culture degrading before incident numbers move.

Industry example

The practice comes from aviation, where NASA has run the Aviation Safety Reporting System since 1976 as a confidential, non-punitive channel for reports of events that did not become accidents. The design decisions are the instructive part: the reporter is protected, the report is short, and the value is explicitly in the aggregate rather than in any single account. Healthcare and the process industries adopted the same model for the same reason — accidents are too rare to learn from fast enough, and near misses are abundant.

Software's version is the blameless postmortem, applied after harm. The near-miss report extends it to the much larger population where harm did not occur: every canary that caught a bad release and every dry-run that showed the wrong object list is a free lesson currently discarded.

Failure scenarios

• A heavyweight template, so nothing is filed and the absence is read as safety.
• Near misses counted as failures in a team metric, which teaches people not to notice them.
• Reports filed into a void, with nothing visibly changing, so reporting decays within a quarter.
• A bar drawn so high that only almost-incidents qualify, discarding the cheap early signal.
• The count reported without the trend, so a drop caused by reporting fatigue reads as improvement.
• Attribution creep, where "what stopped it" becomes "who nearly caused it", after which the channel is finished.

Trade-offs

Near-miss reporting costs a few minutes per report, triage time to cluster them, and the engineering time to act on the clusters — which is the real cost and the one that decides whether the practice survives. A programme that collects and never acts is worse than none, because it spends goodwill and returns nothing.

It also produces a number that looks bad to anyone unfamiliar with it. A rising near-miss count read as "more things going wrong" is the predictable misunderstanding, and it has to be explained every time the audience changes, which is a genuine ongoing cost of using it.

When not to use it

Not before there is a working blameless postmortem practice. Near-miss reporting depends entirely on the absence of blame; introducing it into an organisation where incidents still attract consequences produces no reports and confirms to everyone that reporting is unsafe. Sequence it after.

Also not as a replacement for detection engineering. A near miss is reported by a human who noticed something, so the whole class of failure nobody can notice — degradations with no error signal — is outside it, and that class needs an output-quality signal rather than a reporting channel.

Interview question

Q: Leadership wants a single reliability number that cannot be gamed. You have incident count, mean time to resolve, and availability against an SLO. What do you propose, and what do you add alongside it?

What a strong answer covers: rejecting incident count because the reporting organisation controls its definition and declaring carries a cost, and rejecting mean time to resolve because a mean over a few long-tailed events is dominated by one of them · proposing error-budget burn against journey-level SLOs as the primary number, since nobody can quietly redefine whether a user journey succeeded · adding the time-to-detect distribution rather than its mean, because detection is the part culture most affects · adding near-miss count as the one signal that improves with reporting health, and explaining why a rise is good news · naming the class all of these miss, which is the silent degradation with no error signal, and the output-quality SLI that covers it · and the sequencing point: near-miss reporting only works after blameless postmortems are genuinely blameless.

Quick check

Quiz: Why is a rising near-miss count good news? — Because near misses can only be recorded by people choosing to write them down, so the count rises with reporting health rather than with harm — unlike every metric built on incidents.

Flashcard: Which two reliability signals together show a culture degrading before incident numbers move? — A falling near-miss count and a rising p90 of time-to-detect. Both indicate people are noticing and declaring later, while the harm-based metrics still look flat.