Spend a week sitting with a mid-market SOC team and the thing that strikes you first is not the sophistication of the threats — it is the exhaustion. Analysts cycle through alert queues that refill faster than they drain. High-severity tickets get five minutes of investigation. Medium-severity alerts often get none at all. And yet every metric in the monthly report looks fine: alerts processed, time-to-close, escalation rate. The numbers do not capture what is happening to the people, or to the real threats buried in the noise.
The Numbers Behind Alert Fatigue
The phrase "alert fatigue" has become so commonplace that it risks losing its meaning. Let's put the actual numbers on the table.
Industry surveys consistently find that 45 to 65 percent of all SIEM alerts are false positives — events that matched a detection rule but do not represent a genuine threat. In a SOC processing 3,000 alerts per analyst per month, that means somewhere between 1,350 and 1,950 tickets per analyst per month are noise. That is before accounting for the alerts that are technically real events but not adversarial.
The Ponemon Institute's 2024 SOC research found that the average enterprise SOC ignores 28 percent of alerts entirely because there is simply not enough time to investigate them all. Not triaged and closed as false positive — ignored. Tickets that get auto-closed after an age-out period, or that analysts deprioritize when queue depth becomes unmanageable.
That 28 percent is where sophisticated threat actors operate. They know SOC teams are overloaded. They time their operations to generate activity that blends with alert noise or falls into the queue depth where investigation probability drops.
Where Alert Fatigue Comes From
Alert fatigue is not a new problem and it is not primarily caused by bad detection rules. It is a structural consequence of how SIEM-based detection architectures were designed.
The rule proliferation cycle
Detection rules in a SIEM are typically written in response to specific events: a threat intelligence report, a red-team finding, a compliance requirement, a vendor recommendation. Each new rule adds to the alert volume. Rules are rarely retired. Over time, a mature SIEM accumulates hundreds or thousands of rules, many of which overlap, many of which generate high volumes of benign matches, and some of which have not been reviewed since they were deployed three years ago.
Security teams face a perverse incentive here. Deleting a rule feels risky — what if it was catching something important? — so the default is to keep everything. Alert volume grows monotonically. Analyst capacity does not.
The tuning treadmill
The standard response to alert fatigue is tuning: adding exceptions and exclusions to noisy rules to reduce false positives. Tuning works, but it is expensive (analyst time to investigate false positives before building exceptions) and it is not durable. Environment changes — new software, new infrastructure, new user behavior — regenerate the noise. Tuning is a continuous maintenance task, not a one-time fix.
In environments with rapid infrastructure change (cloud-first companies, companies going through M&A), the tuning burden can exceed available analyst time, creating a steady-state of high alert volume regardless of how much tuning work is done.
The signal-to-noise architecture problem
The deeper issue is that most SIEM correlation rules are designed to match single events or simple event sequences. They fire when a specific thing happens. They do not ask whether that thing, in the context of everything else this entity has been doing for the last two weeks, looks adversarial.
An adversary using living-off-the-land techniques will generate individual events that look completely benign. PowerShell execution: benign (IT uses it constantly). WMI remote connection: benign (monitoring tools do this). New service registration: benign (software deployments do this). But PowerShell to WMI to new service registration to outbound connection to a flagged IP? That is a kill-chain fragment worth investigating. Single-event rules cannot see that pattern.
What Alert Fatigue Costs in Practice
The business impact of alert fatigue is a specific set of adverse outcomes that follow from a predictable mechanism.
- Missed detections: Real threats get buried in noise and time out. Average dwell time extends. IBM's 2025 breach cost data shows cost increases of roughly $500K for every additional week of undetected access against the $4.45M average breach cost.
- Analyst burnout and attrition: High-volume, low-signal work is demoralizing for skilled analysts. Attrition in overloaded SOC environments runs 35 to 40 percent annually in some organizations. Replacing a Tier-2 analyst costs $150K to $200K in recruiting, onboarding, and productivity ramp-up.
- Investigation quality degradation: When analysts spend 60 percent of their time on false positives, they have 40 percent for everything else: threat hunting, incident response, detection engineering. Those activities — the ones that actually reduce risk — get compressed or eliminated.
- Desensitization: Repeated exposure to false positives trains analysts to expect that alerts are probably noise. This cognitive pattern affects even motivated, skilled analysts. It is a predictable response to incentive structures that reward speed over depth.
The Structural Fix: Signal Prioritization Over Rule Tuning
Tuning reduces individual rule noise. It does not change the underlying architecture that produces alert fatigue. The structural fix requires moving from event-volume management to signal prioritization — asking "which of these events are adversarially significant in context?" rather than "which of these events match a rule?"
This is a different computational problem. It requires:
- Cross-signal correlation across telemetry sources (endpoint, network, identity, cloud)
- Behavioral baseline modeling to distinguish anomalous from normal for each entity
- Kill-chain contextualization to assess whether an event fits an adversarial progression
- Risk scoring that accounts for asset criticality, user privilege level, and threat actor TTP relevance
The output of this architecture is not fewer alerts with lower false positive rates — it is prioritized threat narratives: assessed, contextualized findings that tell an analyst what the adversary is doing, not just what event occurred.
What "Good" Signal-to-Noise Looks Like
We have seen SOC environments operating at effective false positive rates under 10 percent for escalated findings — not because their SIEM rules are better tuned, but because the escalation layer between raw SIEM alerts and analyst queue performs multi-dimensional analysis before escalating. Of 50,000 daily SIEM events, perhaps 800 become candidate signals. Of those 800, perhaps 12 become analyst-facing findings. All 12 warrant investigation. Eight resolve as confirmed incidents or confirmed misconfigurations. Four are genuine false positives at the escalation layer.
That is not a 10 percent false positive rate on raw alerts — the raw alert false positive rate is still above 50 percent. It is a 33 percent false positive rate on analyst-facing escalations, with coverage of the genuine threats in the raw stream. The analyst is spending their time on findings that matter.
Alert fatigue is not solved by faster analysts or more analysts. It is solved by architecture that performs the signal-to-noise separation before the analyst ever opens a ticket.
The 45-to-65 percent false positive rate is an industry average, not a law of physics. It describes what happens when detection architecture optimizes for coverage breadth without a prioritization layer between raw events and analyst attention. The teams operating below that baseline have not found better rules — they have added a processing layer that understands adversarial context. That is where the structural solution lives.
