> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootly.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What Is Alert Fatigue?

> Alert fatigue is the desensitization that sets in when responders receive too many alerts, causing real problems to be missed. Learn the causes and the fixes.

**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](/alerts/alert-deduplication).
* **Grouping.** Bundle related alerts—same service, same failure window—so responders see one coherent event, not twenty fragments. See [alert grouping](/alerts/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](/alerts/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](/alerts/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.

## Related terms

* [What Is Incident Triage?](/glossary/incident-triage)
* [What Is MTTR?](/glossary/mttr)
* [What Is Incident Management?](/glossary/incident-management)

Browse all definitions in the [incident management glossary](/glossary).