A flood of unimportant alerts teaches users the rational response is to stop paying attention

What it is

The alert system and its users form a behavioural feedback loop: when alerts are frequent and mostly unimportant, the user's rational strategy is to lower the attention given to alerts — first skimming, then deferring, finally conditioned ignoring. Once this cry-wolf loop forms, the genuinely fatal alert is processed by the same ignoring mechanism. Alert fatigue is not an attitude problem; it is a behaviour trained by the system's own false positives.

Why it happens

The training works through signal-to-noise shaping of strategy: the cost of processing an alert is fixed (read, judge, act), while an alert's value depends on the probability it is real — when history shows nine no-events out of ten alerts, a single alert's expected value drops below the cost of immediate handling, and ignoring becomes the reinforced optimum. The learning is fast and hard to reverse: a few months of false positives build the ignoring habit, and rebuilding trust needs a quiet period far longer than the polluting one. System-side false positives usually come from three sources: thresholds too tight (normal fluctuation flagged as abnormal), no tiering (spikes weighted the same as disasters), and no deduplication (one incident firing dozens of derivative alerts). The countermeasures map one to one: calibration, sustained-window tiering, and root-cause grouping.

Where it stops holding

The goal is not the fewest alerts but the optimal signal-to-noise ratio: over-damping (very long windows, very loose thresholds) creates a quiet but sluggish system that misses exactly the high-value early signals. The healthy metric is not "zero alerts" but "every alert actionable" — the recipient can say what this alert made them do; if not, the alert should be retired. Fatigue also has an organisational dimension: on-call rotation and alert-ownership systems shape where ignoring concentrates; a team receiving the same low-quality alerts long-term is the fatigue hotspot, and audits should measure response rates per receiving group rather than global averages.

Applying it

• Hold a regular alert audit: count triggers, acknowledgement rate, and mean handling time per rule; low-acknowledgement rules enter the pruning queue.
• Run new alert rules in shadow mode (log only, no push) until their signal-to-noise proves out before pushing.
• Verification: track the trend in alert acknowledgement times; a steadily lengthening trend means fatigue is accumulating — tighten the rules now.

Related

• Same group: U7.04.1 Thresholds convert a continuous metric into two discrete states · U7.04.2 The threshold's rationale must be visible and adjustable · U7.04.3 Single-point breaches and sustained breaches deserve different responses · U7.04.5 Alerts must point to the executable next step, not just report the value
• Nearby: U7.01.3 Stacking unrelated views scatters attention · U7.04.3 Single-point breaches and sustained breaches deserve different responses
• Search terms: alert fatigue · false positive rate · alert tuning