What is alert fatigue?
Engineering culture and software practice
Alert fatigue is the desensitisation that sets in when people receive too many alerts, most of them unimportant or requiring no action, so that genuine warnings get missed, ignored or switched off. Documented first in clinical medicine, where the Joint Commission warned of alarm-related patient deaths, it is now a standing problem for on-call engineers, security teams and anyone whose inbox has become an alarm panel. Pager fatigue is the on-call version of the same effect.
What this means
When something alerts you constantly and almost none of it matters, you stop paying attention. This is not carelessness; it is a predictable human response to a poor signal. If the smoke alarm goes off every time you make toast, you take the battery out, and then it cannot warn you about a real fire. Alert fatigue is that pattern at scale, across pagers, dashboards, security tools and email.
The problem is one of signal, not of effort. People do not miss important alerts because they are lazy; they miss them because the important ones are buried in a flood of unimportant ones, and the brain learns, correctly, that most alerts can be safely dismissed. That learned dismissal then applies to the rare alert that actually mattered.
It has a name because the fix is counter-intuitive. The instinct when something is missed is to add more alerts or make them louder. That makes fatigue worse. The real remedy is fewer, better alerts: each one important, urgent and genuinely needing a person to act.
Why it matters
The cost of alert fatigue is the one real warning that gets lost. In medicine that has meant patient deaths; the Joint Commission recorded ninety-eight alarm-related events over about three and a half years, eighty of which resulted in death. In security it means a genuine intrusion sitting unread among thousands of false positives. In ordinary operations it means the outage nobody noticed because the alert looked like all the others.
Every organisation now has a version of this, because everything alerts. Email rules flag messages nobody reads, chat tools ping constantly, monitoring dashboards glow amber by default, and security products raise warnings faster than anyone can triage them. The more tools a business adds, the more alert streams it acquires, and without deliberate design the streams merge into undifferentiated noise that trains everyone to ignore them.
There is a direct wellbeing cost too. Being on call for a system that pages relentlessly, most of it needless, is a known driver of stress and burnout, and burnout worsens the fatigue in a reinforcing loop: tired people miss more, which prompts more alerting, which tires them further. Treating alert volume as a wellbeing issue as well as an operational one is not soft; it is how you keep the people who catch real problems able to catch them.
AI enters on both sides. AI-driven monitoring can generate even more alerts, deepening the flood, and much of the marketing promise around AI in operations and security is precisely about triaging that flood, grouping related alerts and suppressing noise. That promise is real but unproven in any given setting, and an AI triage layer that hides the wrong alert creates a new failure mode, so it should be adopted with the same scepticism as any other alerting change.
How it works
Where the term came from
Alert fatigue was first documented and named in clinical medicine, not in software. A widely cited 2006 systematic review in the Journal of the American Medical Informatics Association by Heleen van der Sijs and colleagues found that clinicians overrode computerised drug-safety alerts in forty-nine to ninety-six percent of cases, and identified alert fatigue from a poor signal-to-noise ratio as a leading cause. The patient-safety framing was cemented by the Joint Commission's Sentinel Event Alert issue 50, "Medical device alarm safety in hospitals", published on 8 April 2013, which reported that an estimated eighty-five to ninety-nine percent of alarm signals require no clinical intervention, leaving staff desensitised. The non-profit ECRI has ranked alarm hazards at or near the top of its annual Top 10 Health Technology Hazards list for years, placing "alarm hazards" at number one in its 2015 edition. The term then migrated into IT monitoring, security operations and site reliability engineering, where Google's SRE workbook chapter on alerting on service level objectives states the governing rule plainly: alerts should be actionable.
Why it happens
The mechanism is base rates. When the thing you are watching for is rare, even a small false-positive rate produces overwhelmingly more false alarms than real ones. A detection system running over a million events a day at a 0.1 percent false-positive rate produces a thousand false alerts daily, enough to swamp any human. Add alerts that carry no consequence for ignoring them, and alerts that nobody owns, and the population learns to dismiss the lot. Security operations research puts typical false-positive rates between fifty and eighty percent and finds large shares of alerts going uninvestigated.
What a good alert looks like
The rules experienced teams apply are strict. A good alert is actionable, meaning there is a specific thing a person can do about it; urgent, meaning it needs doing now rather than whenever; and genuinely in need of a human, rather than something a machine could handle. Anything that fails these tests should be a log entry, a report or a dashboard item, not an interruption. Google's approach of alerting on user-facing objectives rather than on every internal blip is a direct application: page a person only when users are actually being harmed.
Measuring and fixing it
Fatigue can be measured: alerts per shift, how often alerts are acknowledged versus silenced, how many are closed as false positives, and how the backlog of uninvestigated alerts is trending. The fixes follow from the causes: alert on the symptoms users actually feel, de-duplicate and group related alerts, give every alert an owner, and ruthlessly delete alerts that no one acts on. Fewer alerts, each meaning something, restores the signal.
Examples
A GP practice installs a new prescribing system that pops a warning on almost every prescription, most of them trivial interactions. Within weeks the clinicians click through every warning by reflex, and a genuinely dangerous interaction is dismissed the same way. The practice manager, recognising classic alert fatigue, works with the supplier to switch off the low-value warnings and reserve pop-ups for the serious interactions, restoring the meaning of a warning.
A software team of eight is on call for a service that pages whenever any internal metric wobbles, often several times a night, almost always harmlessly. Morale collapses and a real outage is missed because the on-call engineer had silenced the pager. The team rebuilds its alerting to fire only when customers are actually affected, measured against a service objective, and deletes dozens of internal alerts. Pages drop by an order of magnitude and the ones that remain are trusted.
A charity's finance officer has set up email rules that flag every transaction over a small threshold, so the flagged folder fills with routine payments. A genuinely suspicious payment sits unnoticed among them for a fortnight. The officer raises the threshold, groups routine payments into a weekly summary, and reserves an immediate flag for the handful of patterns that truly warrant a same-day look, turning a noisy folder back into a signal.
Common misunderstandings
The first misconception is that alert fatigue is a discipline problem, solved by telling people to pay more attention. It is not; it is a signal-design problem, and it is a predictable human response to a poor signal that no amount of exhortation fixes.
The second is that more alerts mean more safety. The opposite is usually true past a point: adding alerts dilutes the important ones and trains people to ignore all of them. Safety comes from fewer, better alerts.
The third is that missing a real alert is the fault of the person who missed it. This is where a just-culture view matters, and where the term differs from a death march. A death march is burnout driven by an impossible schedule and deadline pressure; alert fatigue is about attention and signal design, not deadlines. When someone misses the one real page among hundreds of false ones, the honest response is to fix the alerting that set them up to fail, not to blame the individual, in the same spirit as a blameless post-mortem.
The fourth is that alert fatigue is only an engineering or clinical concern. It afflicts anyone whose tools cry wolf, from a finance officer's flagged-payments folder to a manager's chat notifications. The mechanism is identical wherever the ratio of noise to signal is high.
The fifth is that AI will simply solve it. AI triage can help, but it can also generate more alerts, and an AI layer that suppresses the wrong alert introduces a fresh way to miss the thing that mattered.
Risks and boundaries
The sharpest boundary is that reducing alerts is not the same as reducing vigilance. Deleting noisy alerts is right; deleting alerts that are merely inconvenient but genuinely important is dangerous. The test is whether an alert is actionable and reflects real harm, not whether it is annoying, and cutting on annoyance alone can silence a real warning.
A second boundary is that some domains cannot tolerate missed signals and must accept a noisier baseline. In medicine and safety-critical settings the balance between too many alarms and a missed critical one is genuinely hard, and the clinical literature is careful to say that overriding an alert is often clinically justified rather than always a failure. The goal is a better signal, not simply a quieter one, and the two are not automatically the same.
The live debate is over automation and AI in triage. Grouping, de-duplication and machine-assisted prioritisation clearly help in high-volume security operations, but the evidence for any specific tool in any specific setting is thin, vendor claims run ahead of independent proof, and an over-trusted automated filter can hide the rare true positive. Adopt such tools as you would any alerting change: measure the false-negative rate, not just the reduction in volume, because the number that matters is how often a real alert still gets through.
What to do next
Count your alerts before changing anything. For a critical system or team, measure how many alerts arrive per shift, how many are acted on, and how many are dismissed or silenced. A high dismissal rate is the diagnostic sign of fatigue and the case for reform.
Adopt one rule for every alert: it must be actionable, urgent and need a human. Anything failing that test becomes a log, a report or a dashboard item, not an interruption. Prefer alerting on things your users or beneficiaries actually feel over alerting on internal readings.
Give every alert an owner and delete the orphans. An alert nobody is responsible for acting on is noise by definition, and removing it improves the signal for everything else. Review the alert set regularly, because it degrades over time as new tools add streams.
Protect the people on the receiving end. Treat relentless out-of-hours alerting as a wellbeing risk, and when a real alert is missed, fix the signal rather than blaming the individual. If you trial AI-assisted triage, judge it by whether real alerts still get through, not by how much quieter it makes things.
FAQs
What is alert fatigue in plain terms?
It is the desensitisation that happens when you get so many unimportant alerts that you start ignoring all of them, including the rare one that matters.
Where was it first documented?
In clinical medicine. A 2006 review found drug-safety alerts overridden in forty-nine to ninety-six percent of cases, and the Joint Commission's 2013 alarm-safety alert linked alarm fatigue to patient deaths.
How is pager fatigue related?
Pager fatigue is the on-call engineering version of alert fatigue: too many pages, most needless, so real ones get silenced or missed.
Why does adding more alerts make things worse?
Because it dilutes the important ones and trains people to dismiss the whole stream. Safety comes from fewer, better, actionable alerts.
How do I know if my organisation has it?
Measure alerts per shift and how many are dismissed or silenced. A high dismissal rate, or a real problem that was missed, is the tell-tale sign.
What makes a good alert?
It is actionable, urgent and needs a human. If none of those hold, it should be a log or a report, not an interruption.
Can AI fix alert fatigue?
AI can help triage and group alerts, but it can also generate more, and an over-trusted filter can hide a real one. Judge any tool by whether genuine alerts still get through.
How is this different from a death march?
A death march is burnout from an impossible schedule and deadline pressure. Alert fatigue is about attention and signal design, not deadlines.