All-user notifications train people to ignore

What it is

Alert fatigue specifically names what happens when members repeatedly receive broadcast notifications that are irrelevant or require no action from them, and gradually learn to ignore, defer, or mute altogether. It is about the broadcast form specifically, not "too many notifications" in general — a targeted, one-to-one alert sent frequently to the actual responsible person usually does not produce the same fatigue, because the recipient can verify each one is relevant.

Why it happens

The broadcast problem is a mismatch in cost structure: the sender reaches everyone with a single action and bears no responsibility for judging relevance per recipient, while the receiving cost is paid individually by every member regardless of whether the message applies to them. This is a classic externality — the convenience of broadcasting accrues entirely to the sender, while the attentional cost is spread across the whole audience.

A signal-detection framing captures the second-order mechanism: every broadcast poses an "is this relevant to me" judgment to the recipient, and if most broadcasts turn out to be false alarms, recipients raise the threshold they require before treating any signal as genuinely important — exactly like habituating to a false alarm. Once the threshold rises, the coping strategies people adopt — deferred reading, batch clearing, outright muting — are indiscriminate: they operate at the level of the channel, not the content, so they cannot suppress noise while preserving sensitivity to a truly urgent case. Broadcast notification does not train people to discriminate; it trains them to discount the channel wholesale, and the next genuinely all-hands event pays the same discount.

Studying it

• Paradigm: track broadcast frequency, opening delay, mute settings, and actual response to critical events, paired with scenario tests — show members a mixed history of broadcast noise and real emergencies and measure whether, and how slowly, they can tell them apart afterward.
• Variables: broadcast share of all notifications, relevance (role-tagged, whether the recipient actually needed to act), required action, opening delay, mute rate, response time to critical events, and trust.
• Methodological caution: low response is not automatically fatigue — the task may already have been handled by someone else and required no response from this person at all. Judging fatigue requires cross-referencing role and actual responsibility; open rate or response rate alone will overstate it.

Where it stops holding

Broadcasting is appropriate for events with genuine all-hands safety impact, systemic outage, or a decision requiring shared awareness — but the trigger conditions must be explicit and auditable, not left to a sender's ad hoc judgment. This effect is marginal in small teams where members already know each other's responsibilities well enough that a "sent to everyone but irrelevant to most" broadcast almost never occurs — people can judge from experience whether a message concerns them. The mismatch, and the fatigue it produces, becomes significant once scale and role differentiation grow; that is the regime in which the effect is actually observed. Copying everyone is not transparency by itself — transparency means the right people see it, while broadcast only guarantees that everyone does.

Applying it

• Restrict broadcast to explicitly listed trigger conditions and require the sender to actively choose audience and required action before sending, rather than defaulting to everyone.
• Carry general updates in a digest, bulletin, or opt-in subscription instead of disguising them as urgent interruptions.
• Give recipients a "mark irrelevant" and preference-adjustment control, and periodically review aggregated feedback against actual broadcast necessity.
• Verification: audit what share of past broadcasts genuinely required action from each recipient, and compare response speed to critical events before and after high-noise periods — a measurable slowdown is the direct evidence that fatigue is actually occurring.

Related

• Same group: V6.05.1 Notification volume grows fastest in collaboration tools · V6.05.3 Push by relevance rather than event
• Nearby: V4.03 Notification and subscription granularity · V5.02 Synchronous and asynchronous work
• Search terms: alert fatigue · notification habituation · broadcast messaging · signal detection