The alert queue nobody reads
The average enterprise SOC processes 4,484 alerts a day. StrangeBee and Cymulate both report that up to 90 percent of those alerts are false positives. Cyber Sierra's triage data says 62 percent of alerts are never investigated at all. Cymulate puts the average triage time on a false positive at 25 to 30 minutes per event, and estimates the global cost of false-positive alert handling at $3.3 billion a year. The SANS 2025 SOC Survey concluded that 66 percent of SOC teams cannot keep pace with the volume they receive.
Anton Chuvakin, formerly of Gartner and Google Cloud, summarized it in one sentence: "False alerts times hard to triage alerts times lots of them equals endless pain. If you are taking 2 hours to tell that the alert is a false positive, this whole SOC thing will never work."
This post is about why that ratio holds almost everywhere, why in-SIEM tuning has failed to close it over a decade of effort, and what changes once detection logic and data preparation stop living in the same layer.
What a false positive actually is
A false positive is not a single failure mode. It is three distinct categories that tend to get conflated in vendor marketing.
The first is a true benign event that matches a detection rule by coincidence. A PowerShell script executed at midnight from a service account that happens to run a patching job. A login from a corporate laptop over a VPN that lands in a geolocation block. A binary that hashes to an indicator on a stale threat feed. The rule fires exactly as designed. The event is not a threat.
The second is a rule that is structurally over-broad. A detection written for a generic behavior, like "outbound connection on a non-standard port," catches the three malware families it was designed for and also every database replication job, every developer's SSH tunnel, and every partner API on a custom port. The rule is doing exactly what it says, and the output is mostly noise.
The third, and the most common, is a data-quality failure that produces ambiguous input. Two different log sources describe the same authentication event with different field names. An EDR product reports a parent-child process relationship in a structure the correlation engine does not understand. A firewall logs a blocked session without the post-NAT destination the threat rule requires. The rule cannot evaluate cleanly, and it errs toward firing.
The first category is inherent to probabilistic detection. The second and third are the ones that scale with deployment size, and they account for the bulk of the 90 percent ratio in most environments we have audited.
Why in-SIEM tuning has not solved this
Every SIEM vendor has a tuning story. Splunk has eventtype and tags, Sentinel has analytics-rule suppression, Elastic has exceptions and watcher overrides, QRadar has building blocks. All of them allow an analyst to refine a detection after the fact, usually by adding exceptions: "suppress this rule when the source is this subnet, the user is in this group, the process is on this allow list."
The failure mode is structural. Exception lists grow linearly with the size of the environment and the age of the deployment. A three-year-old detection with fifteen exceptions is harder to reason about than the original rule. An analyst who inherits that rule from a predecessor does not know which exceptions are still valid. Over time the exception list becomes the rule, and the original intent is lost. Gartner's Chuvakin described the resulting ecosystem as "a market of lemons," noting that MSSPs "build broad, generic detection logic, and then spend their time tuning out false positives on live environments rather than having good detection logic."
The other structural problem is that tuning happens in the analytics layer, where the data is expensive, late-arriving, and schema-flattened. A Splunk search that discovers a new false-positive pattern runs across indexed data that has already been licensed, stored, and replicated. The fix applies to future events only. The indexed history of the false positives remains, paid for, searchable, and useless.
What the analyst cost actually looks like
Advanced Threat Analytics surveyed roughly 50 MSSPs on false-positive handling. Forty-four percent reported false-positive rates of 50 percent or higher. Twenty-two percent reported rates between 75 and 99 percent. Forty-five percent of analysts investigate 10 or more alerts daily. Sixty-four percent require 10 or more minutes per alert, which at the upper end of both distributions means five or more hours per analyst per day spent on events that are not threats.
The coping mechanisms are worse than the pain. Thirty-eight percent of MSSPs admit to ignoring entire alert categories. Twenty-seven percent report turning off high-volume alerting features entirely. Seventy-one percent of SOC analysts rate their job pain at 6 to 9 out of 10 (Simbian AI). SOC analyst turnover exceeds 25 percent annually in many operations, with average tenure under 18 months (Exaforce), and every departure takes institutional tuning knowledge with it. Exaforce describes the resulting pattern as a sawtooth: detection quality climbs after onboarding, degrades with churn, and climbs again with the replacement.
The downstream effect on security outcomes is measurable. When the queue is unmanageable, analysts develop filtering heuristics that are not documented anywhere: which rules to skim, which client's alerts to deprioritize, which categories to batch. None of those heuristics appear in the incident response plan. All of them are evaluated during the next audit, usually after an incident.
The pipeline-layer fix
A data pipeline sits between log sources and the SIEM. It receives raw events, applies transformations, and forwards the result to one or more destinations. The relevant capabilities for alert fatigue are deduplication, structural filtering, normalization, and enrichment, applied before the data is indexed, not after.
Deduplication is the simplest win. Cribl's Suppress function removes duplicate events within a configurable key and time window. Most environments we audit have 30 to 50 percent duplication on authentication events alone, caused by multiple log sources reporting the same session (the firewall, the proxy, the identity provider, the EDR agent on the endpoint, the SIEM's own agent). Before Suppress, each copy triggers its own rule evaluation. After Suppress, the SIEM evaluates each event once, and the rule fires once.
Structural filtering handles the second category of false positives. The Drop function removes entire event classes from the stream when they have no detection value. A stream of DHCP renewals, health-check pings from load balancers, or success-only events from high-chattering services can be excluded entirely at the pipeline, archived to object storage for compliance, and never seen by the correlation engine. This is category-level noise reduction, not per-rule exceptions.
Normalization is the fix for the third category, the data-quality driven false positives. The pipeline parses and remaps every source to a canonical schema before the SIEM receives the event. For Sentinel that means ASIM. For Elastic that means ECS. For Splunk that means a pre-parsed, field-extracted payload that removes props.conf dependency for the source. When detection rules evaluate against a canonical schema, they no longer fire on ambiguous field mappings, and the false-positive rate from data quality collapses to near zero.
Enrichment is the final layer. An Eval function adds context to every event before it reaches the SIEM: client tenant ID, asset criticality, user group, geolocation category, time-of-day bucket. Detection rules can then condition on that context directly, with filters like "alert on PowerShell execution from a service account in the finance tier during business hours outside the patching window." That is far more specific than what an in-SIEM exception list can express.
A Splunk example
A Splunk environment ingesting 500 GB a day, with Enterprise Security enabled, typically carries hundreds of correlation searches. A substantial share of the false positives in that environment come from three sources: duplicate events from overlapping log sources, authentication successes that trigger brute-force rules because the source IP was not enriched, and process-execution events where the parent-child relationship was lost in transit.
A pipeline in front of Splunk applies Suppress to the duplicate authentication stream (30 to 50 percent reduction immediately). It applies Drop to high-volume success events that no correlation search consumes. It applies a Pack to normalize the EDR's parent-child process structure to Splunk's CIM model before indexing. The correlation searches see clean, deduplicated, canonically-typed data. Rule false-positive rates drop because the ambiguity the rules were firing on is gone. Splunk admin cycles spent on props.conf and transforms.conf drop because the parsing happens upstream.
A Sentinel example
Sentinel's 512 analytics-rule cap per workspace becomes a capacity problem on exactly this issue. Analysts write rules that compensate for inconsistent source parsing, and each compensating rule eats into the cap. A pipeline in front of Sentinel normalizes every source to ASIM schema before the Data Collection Rule fires. The analytics rule library collapses from dozens of source-specific variants per detection to a single ASIM-based rule. The 512-rule cap becomes irrelevant because the ruleset is smaller by construction.
Simultaneously, the commitment-tier cost per workspace drops with the volume reduction. Less data means a smaller commitment, a smaller bill, and fewer events for the rules to evaluate, which reduces the Sentinel alert queue's input rate proportionally.
A 30-day pilot
Route a single noisy log source (a firewall, an authentication server, an EDR stream) through a pipeline for 30 days. Configure Suppress on the duplicate key you expect to see. Configure Drop on the event types that have no correlation search consuming them. Configure a Pack or equivalent to normalize the schema.
Measure four things. The reduction in event count reaching the SIEM. The change in the alert count for rules that consume that source. The analyst time spent on false positives tied to that source. The number of open exception entries maintained for rules that touched that source.
One source is enough to prove the architecture. If the alert count drops without affecting true-positive detection rate, the rollout to the rest of the environment is mechanical. Most engagements recover 40 to 60 percent of SOC analyst capacity within the first quarter, not by replacing the analyst workflow but by removing the events the workflow was never going to resolve productively.
The structural takeaway
Alert fatigue is not a tuning problem. It is a data-preparation problem that has been treated as a tuning problem for a decade, and the result is the distribution we have today: 4,484 alerts a day, 90 percent false positives, 62 percent ignored, 71 percent of analysts burned out. Tuning inside the SIEM addresses the symptom at the most expensive layer in the stack, late in the pipeline, where the data has already been indexed and billed.
Preparing the data before it reaches the SIEM (deduplicating, filtering, normalizing, enriching) addresses the cause at a layer where those operations are cheap, reversible, and auditable. The detection rules get cleaner input. The analysts get a shorter queue. The architecture gets an explicit place where "what the SIEM sees" is separated from "what the sources emit," and that separation is the thing the industry has been missing.
There is no silver bullet for detection logic itself. There is a silver bullet for the false positives that are not detection-logic failures at all, and it lives one layer upstream from where the industry has been looking.