What Is Alert Fatigue?

Last verified on Nov 8, 2026.

Alert fatigue is the loss of attention that follows from too many alerts, especially ones nobody can act on. The Google SRE book puts the consequence plainly: the fatigue from low-priority alerts that bother the on-call engineer every hour or more often can cause serious alerts to be treated with less attention than they need.

It is a design problem with the alerting rules, not a discipline problem with the people reading them.

Where It Comes From

The SRE workbook describes an on-call engineer paged about a hundred times in a typical 24-hour shift, where many pages are ignored and the real problems are buried. Typical causes:

• Alerts with no action. Nothing a human can do that the system could not do itself.
• Cause-based alerts. CPU at 80% on one host, with no user effect.
• Duplicates. Several rules fire for one failure, so one problem produces many pages.
• Thresholds without slack. A one-minute blip pages someone.
• No guidance. The alert arrives with no playbook entry.

Google's workbook says a low signal-to-noise ratio raises the risk of alert fatigue, and that the way to keep it high is to make every alert immediately actionable.

Rules for Pages

The SRE book's philosophy on pages is short enough to print:

• Every time the pager goes off, you should be able to react with urgency. You can do that only a few times a day before you become fatigued.
• Every page should be actionable.
• Every page response should require intelligence. A robotic response means it should not be a page.
• Pages should be about a novel problem or an event that has not been seen before.

Prometheus's alerting guidance agrees: alert on symptoms linked to end-user pain, keep the number of alerts low, allow slack for small blips, and avoid pages where there is nothing to do. For online serving systems it suggests alerting on latency and error rates high in the stack, and paging on latency at only one point.

Questions to Ask of Every Alert

The SRE book gives questions for each rule. Ask:

1. Will I ever be able to ignore this alert, knowing it is benign?
2. Does it definitely mean users are affected, and can cases like diverted traffic or test deployments be filtered out?
3. Can I act on it, is the action urgent, and could it be automated?
4. Is someone else being paged for the same issue?

An alert that fails these tests should become a ticket, a dashboard, or nothing.

Page Less by Burning Budget

Alerting on error budget consumption turns the question into "how fast are we spending the budget." Google's workbook recommends starting points for multiple burn rate alerts:

The thresholds depend on the service and its baseline page load. The slow-burn case becomes a ticket for the next working day because there is time to fix it. The workbook weighs these options on precision, recall, detection time, and reset time, so you can see what each choice costs.

Clean-Up Checklist

1. List every alert that fired last month and how many led to action.
2. Delete alerts nobody acted on, or move them to tickets.
3. Replace cause alerts with the symptom they predict.
4. Merge rules that fire together for one failure.
5. Add a runbook entry to each remaining page.
6. Track pages per shift and review the number monthly with the on-call rotation.

In Sazabi

Sazabi, an AI-native observability and security platform, opens an issue that arrives with the agent's analysis of what happened and why. Repeats of the same problem fold into the open issue rather than creating duplicates. Delivery rules can match by severity, so you can send only high and critical issues to a pager. The notification docs say issue updates go out at most once per issue a day unless severity rises again. See also the guide on novel events and MTTR.

Frequently Asked Questions

What is alert fatigue in simple terms?

It is what happens when people get so many alerts, especially ones that need no action, that they stop reacting quickly to any of them, including the one that matters.

What causes alert fatigue?

Alerts that are not actionable, alerts on causes instead of user-facing symptoms, duplicate pages for the same problem, thresholds with no slack for short blips, and alerts with no instructions for what to do.

How many alerts is too many?

Google says you can react with urgency only a few times a day before becoming fatigued, and targets at most two incidents per on-call shift. If your on-call gets paged around a hundred times in a shift, most pages are noise.

How do you reduce alert fatigue?

Delete or downgrade alerts nobody acts on, page on symptoms and SLO burn instead of causes, move slow-burn problems to tickets, group duplicates, and attach a playbook to every page that remains.

Sources

1. The pager philosophy: urgent reaction only a few times a day before fatigue, every page actionable and requiring intelligence, symptoms over causes, and the questions to ask of every alert rule (accessed Nov 8, 2026)
2. Misconfigured monitoring causes operational overload; low-priority alerts that fire hourly induce fatigue that causes serious alerts to get less attention; paging alerts should match SLO-threatening symptoms and be actionable (accessed Nov 8, 2026)
3. Low signal-to-noise raises the risk of alert fatigue; every alert should be immediately actionable and have a playbook entry; the case of an engineer paged about a hundred times in a shift (accessed Nov 8, 2026)
4. Multiple burn rate alerts: page at 2% budget in one hour or 5% in six hours, open a ticket at 10% in three days; precision, recall, detection time, and reset time (accessed Nov 8, 2026)
5. Prometheus guidance: keep alerting simple, alert on symptoms tied to end-user pain, have as few alerts as possible, and avoid pages where there is nothing to do (accessed Nov 8, 2026)
6. An issue arrives with the agent analysis, repeats fold into the open issue, and severity decides which channels it reaches (accessed Nov 8, 2026)
7. Delivery rules can match by severity; issue updated notifications are sent at most once per issue a day unless severity rises again (accessed Nov 8, 2026)