Skip to main content
Alert fatigue is the desensitization that sets in when responders receive so many alerts—especially noisy, low-value, or false ones—that they begin to ignore, mute, or slow-walk them. It is dangerous because it degrades exactly the behavior alerting exists to create: fast, attentive response. A team suffering from alert fatigue will eventually sleep through the one page that actually mattered.

​
What causes alert fatigue?

Alert fatigue is rarely caused by one bad alert. It accumulates from systemic problems:
  • Noise. Alerts that fire for conditions nobody needs to act on—a CPU spike that self-resolves, a threshold set years ago and never revisited.
  • False positives. Alerts that cry wolf. Each one teaches responders that pages can be safely ignored, and that lesson is hard to unteach.
  • Duplication. One underlying failure triggering twenty alerts from different monitors, each paging separately.
  • Over-paging. Routing everything to a human pager regardless of urgency, so a full disk on a staging server interrupts dinner the same way a production outage does.
  • Wrong recipients. Alerts sent to people who can’t act on them, who then either ignore them or spend effort re-routing them by hand.
The common thread is a broken signal-to-noise ratio: when most alerts don’t require action, responders rationally stop treating any alert as if it does.

​
What are the consequences of alert fatigue?

The costs show up in two places—systems and people:
  • Missed or delayed incidents. The real SEV1 arrives looking exactly like the fifty ignorable pages before it. Detection-to-response time stretches, and outages run longer.
  • On-call burnout. Interrupted sleep and constant context-switching are among the most-cited reasons engineers leave on-call rotations, and sometimes teams entirely.
  • Eroded trust in monitoring. Once engineers believe the alerting system is noise, they stop improving it, which makes it noisier—a self-reinforcing spiral.
  • Alert-handling theater. Teams start bulk-acknowledging pages without reading them, which looks fine on dashboards while providing zero actual coverage.
A realistic example: a platform team’s disk-usage alert fires nightly at 3 a.m. because a log-rotation job briefly crosses 85%. After three weeks, the on-call engineer creates a mental rule—“the 3 a.m. page is always the log thing”—and starts acknowledging it from bed without looking. On night 24, the 3 a.m. page is a genuine database disk exhaustion. It gets acknowledged and ignored, and the outage is discovered by customers four hours later.

​
How do you fix alert fatigue?

The fixes attack noise at different points in the pipeline:
  • Deduplication. Collapse repeated firings of the same alert into one incident-worthy notification instead of a page-storm. Rootly supports this via alert deduplication.
  • Grouping. Bundle related alerts—same service, same failure window—so responders see one coherent event, not twenty fragments. See alert grouping.
  • Routing. Send each alert to the team that owns the affected service, so alerts land with people who can act. See alert routing.
  • Urgency tuning. Not every alert deserves a phone call. Map alerts to urgency levels—page immediately, notify during business hours, or just log—so interruptions are reserved for problems that need a human now. See alert urgency.
  • Ruthless pruning. Regularly review which alerts fired, which were actionable, and delete or fix the rest. An alert that has never led to action is a candidate for removal, not a keepsake.

​
How do you know if your team has alert fatigue?

Watch for these signals: pages routinely acknowledged in under ten seconds (nobody reads that fast), recurring alerts with no linked follow-up work, on-call handoff notes that say “you can ignore X,” and engineers negotiating to avoid rotations. A useful metric is the actionable-alert rate—the fraction of pages that led to real action. Healthy teams push this well above half; fatigued teams often sit below one in ten. Browse all definitions in the incident management glossary.