Alert Noise Isn’t an Accident — It’s a Design Decision

In a previous post, The Incident Checklist: Reducing Cognitive Load When It Matters Most, we explored how incidents stop being purely technical problems and become human ones. These are moments where decision-making under pressure and cognitive load matter more than perfect root cause analysis. When systems don’t support people clearly in those moments, teams compensate.

They add process.
They add people.
They add noise.

Alerting is one of the most visible places where this shows up.

The Familiar Pattern

Most engineering leaders have seen some version of this. An alert fires. It goes to:

• a long list of individuals;
• multiple email addresses;
• several phone numbers; and
• one or more chat channels.

On paper, this looks robust. Many eyes. Many paths. And plenty of redundancy. In practice however, response slows. People hesitate. Everyone waits to see who will act first.

The problem isn’t that the alert was wrong. It’s that responsibility was unclear.

When Everyone Sees It, No One Owns It

Many teams can recall an incident where dozens of people were notified at once.
Messages start appearing in chat. A few engineers begin investigating quietly. Others wait. Some assume someone more senior has it covered. Everyone can see the problem, but no one is certain they’re the one who should act first.

Minutes then pass. Not because the team lacks skill, but because the system hasn’t made ownership obvious. This isn’t a failure of individuals. It’s a predictable outcome when responsibility is diffuse.

Noise Doesn’t Appear by Accident

Alert noise is rarely the result of carelessness. It’s almost always the result of good intentions layered over time.

A name gets added after one incident where someone wasn’t notified. Another after a near-miss. A team mailing list after an escalation felt slow. Each decision makes sense in isolation.

Many years later, the alert goes everywhere; but action goes nowhere. What began as a safety measure quietly becomes a source of delay and confusion.

Why Over-Alerting Feels Rational

When alerting doesn’t feel safe, teams compensate socially.

If you’re not confident that: (i) the signal is reliable; (ii) the right person will see it; or (iii) someone will take ownership quickly, then widening the audience feels like the least risky option.

Noise is easier to tolerate than silence. Being interrupted feels better than missing something critical. From that perspective, over-alerting isn’t negligence; it’s a coping mechanism.

In human factors research, this pattern is well understood. Under uncertainty, people optimise for safety as they perceive it in the moment; even when that creates new risks elsewhere.

The Cost of Broadcast Alerting

Broadcast alerting comes with predictable side effects.

• Responsibility diffuses.
  Everyone assumes someone else is handling it.
• Decision-making slows.
  People wait for confirmation before acting.
• Cognitive load increases.
  Engineers spend time interpreting context instead of responding.
• Escalation becomes ambiguous.
  It’s unclear what should happen if nothing happens.

None of this shows up in alert metrics. It shows up in incident timelines, stress levels, and postmortems that say, “We weren’t sure who should act.”

A Brief Analogy

Imagine a cockpit where every warning light alerts every crew member at once, with no clear division of responsibility. Everyone sees the issue. No one is sure who should act first. That wouldn’t be considered a robust safety system. It would be recognised as a design flaw. Software systems are no different.

This Is a Design Problem, Not a Hygiene Issue

Teams often try to fix alert noise by tuning thresholds, reducing volume, or adding documentation. Those things can help, but they don’t address the underlying issue.

Alerting systems encode assumptions about ownership, trust, and how humans behave under pressure. When alerts go to “everyone,” the system is implicitly saying: “We don’t know who should act here.” That’s not a notification problem. It’s an organisational one.

Designing for Action, Not Coverage

High-performing teams design alerting with a different goal in mind – not maximum reach, nor maximum redundancy, but clear action.

They optimise for:

• someone recognising that this is theirs;
• knowing what matters right now; and
• feeling confident enough to act.

That often means fewer recipients, clearer ownership, and signals people trust enough to move on without debate. It can feel riskier at first. Over time, it creates calmer, faster responses, and far less noise.

What Comes Next

In the next post, we’ll look at why large notification lists rarely create accountability, and why being “included” is not the same as being responsible. Because when everyone is alerted, no one is responsible. And that’s a design choice worth examining.