Every conversation about SIEM alert fatigue eventually arrives at the same proposed solution: reduce false positives. Tune the rules. Suppress the noise. If you get the true positive rate high enough, the queue becomes manageable. This logic sounds reasonable. It doesn't survive contact with arithmetic.
The Throughput Equation Nobody Runs
Let's model the actual math. A mid-size enterprise SOC running Splunk or Microsoft Sentinel typically receives somewhere between 8,000 and 15,000 alerts per day across all detection rules and correlation logic. Call it 10,000 for clean numbers. A skilled L1 analyst — handling triage, initial enrichment, prioritization, and handoff or closure — can process roughly 15 to 25 alerts per hour with meaningful attention. Call it 20. An 8-hour shift produces 160 reviewed alerts per analyst.
With a three-person L1 rotation running two shifts, that's roughly 960 alerts reviewed per day. Against 10,000 generated, you're covering less than 10%.
Now apply the false-positive improvement. Suppose your detection engineering team runs a focused tuning sprint and cuts false positives by 40% — an ambitious result. Alert volume drops to 6,000 per day. Coverage improves to 16%. You've made a meaningful dent, but the backlog math hasn't fundamentally changed. 84% of alerts still go unreviewed. The adversary operating in that 84% window has approximately the same dwell time as before the tuning sprint.
We're not saying false positive reduction is wasted effort — it absolutely reduces analyst burnout and improves morale. The point is that it doesn't change the structural problem. Alert volume and analyst throughput are on different growth curves. Security environments expand; detection rules multiply; SIEM telemetry grows as EDR and identity log sources get added. Analyst headcount grows slowly if at all, constrained by hiring markets and budget. The ratio gets worse over time, not better, even with good tuning.
How the Queue Actually Behaves at Scale
The naive assumption is that an unreviewed alert is a neutral state — nothing happens until an analyst reviews it. In practice, alert queues have non-linear behavior. When a queue depth exceeds a few hundred items, triage prioritization breaks down. Analysts can no longer reliably sort by risk — they sort by what's visible, what they recognize, what's loudest. High-severity alerts that share visual characteristics with common false positives get skimmed past. Low-severity alerts that represent lateral movement in progress sit unreviewed for days.
Consider a realistic scenario from a healthcare IT environment: a regional health system running a Splunk deployment with 900 endpoints and 12 connected log sources was generating approximately 7,400 alerts per week across their detection rule set. Their two-person L1 team was reviewing roughly 900 alerts per week — 12% coverage. During a tabletop exercise, the team reconstructed a simulated ransomware event (modeled on common double-extortion patterns). The simulation showed that the initial access event, the initial privilege escalation, and the first lateral movement would all have generated alerts — none in the critical category, all in the high-medium range. All would have fallen within the 88% unreviewed backlog. The dwell time for that simulated attacker, from initial access to data staging, was nine days. Every alert that mattered was in the queue. Nobody reached it.
MTTD vs. Queue Depth: The Real Relationship
Mean time to detect (MTTD) is the KPI most SOC programs track for detection performance. It measures the gap between when a threat first generates observable signals and when an analyst confirms the threat is present. The industry median MTTD for organizations with active SOC programs sits in the 7-to-30-day range, depending on the threat type. For organizations without continuous monitoring, the widely-cited figure is 200+ days.
What's underappreciated is how MTTD is controlled more by queue depth than by detection rule quality. A rule that fires correctly within minutes of an attacker action does nothing for MTTD if the alert sits in a 4,000-item queue for six days before an analyst reaches it. Improving MTTD requires improving throughput — the rate at which alerts are reviewed — not just improving the accuracy of alert generation.
MTTR (mean time to respond) has a similar dependency. Analysts who spend most of their shift processing triage have limited time for the enrichment, context-gathering, and coordination work that drives MTTR down. The queue bottleneck affects both metrics simultaneously.
What Throughput-First Approaches Actually Look Like
A throughput-first approach to alert fatigue treats the queue as the primary constraint to optimize, not the false-positive rate as an end in itself. The mechanisms differ:
Automated triage pre-processing runs enrichment — IP reputation, file hash lookups, user behavior context, asset criticality — before an alert reaches an analyst. When an L1 analyst opens the alert, the relevant context is already assembled. Instead of 8 minutes per alert for enrichment plus 2 minutes for the actual triage decision, you get 2 minutes for the decision. Throughput per analyst roughly quadruples for the enriched alert subset.
Automated verdict on high-confidence false positives is different from traditional suppression. Suppression removes alert classes permanently. Automated verdict closes specific alert instances based on corroborating evidence — the flagged process was launched by a verified software deployment system, the suspicious authentication came from a known VPN endpoint on the approved list, the network connection is to a CDN that serves a whitelisted application. Each closure is logged with evidence, auditable, and reversible. The queue shrinks without the oversight risk of blanket suppression rules.
Priority queue management based on technique severity and asset criticality ensures analysts review in the right order. T1486 (Data Encrypted for Impact — ransomware) affecting a domain controller gets routed before T1566.001 (Spearphishing Attachment) affecting a non-critical endpoint. This sounds obvious, but most SIEM queues are still sorted primarily by time-of-arrival rather than risk-adjusted priority.
The Staffing Math Problem Is Structural
No technology solves the staffing math problem by itself. The cyber workforce shortage — roughly 3.4 million unfilled security roles globally by various industry estimates — means that hiring more L1 analysts is not an available solution for most organizations, especially at mid-market scale. The math requires either reducing alert volume (tuning), increasing analyst effective throughput (automation of pre-work), or both.
The teams that have made meaningful progress on MTTD and alert-to-incident ratio tend to have done three things: they automated the mechanical work at L1 (enrichment, deduplication, context assembly), they invested in detection engineering to reduce noisy rules rather than suppress them, and they built explicit capacity planning that treats analyst throughput as a constraint to be managed, not a pool to be maximized through burnout. None of these are quick wins. All of them are necessary.
Alert fatigue will not be fixed by buying a better SIEM. It will not be fixed by one tuning sprint. It is a structural imbalance between the volume of signals modern environments generate and the human capacity to process them. Addressing it requires treating analyst throughput as the primary engineering constraint, not a secondary concern after detection accuracy.