The Alert Nobody Reads

Operations · June 24, 2026 · 7 min read

Every security operations team eventually develops a queue it does not read. Not officially. Officially every alert is triaged. In practice there is a class of alert that gets closed in three seconds by muscle memory, because experience says it is never anything, and experience is right often enough that the habit survives.

The dangerous property of that habit is that it generalises. Analysts do not learn “this specific rule is noisy”. They learn “alerts of roughly this shape are noise”, and the moment a real event arrives wearing that shape, it is closed in three seconds too.

Volume is the symptom

The usual framing is that there are too many alerts and analysts cannot keep up. That framing suggests hiring, or automation, or a bigger screen.

The more useful framing is that the precision of the queue is too low. If one in fifty alerts represents something worth acting on, no amount of throughput fixes the underlying issue: the queue has trained everyone reading it to expect nothing. Doubling capacity to process twice as many worthless alerts twice as fast does not improve outcomes.

Precision, not volume, is what determines whether the queue is believed. A team handling forty alerts a day where a third matter is in a far better position than a team handling four hundred where six do.

Why noisy detections survive

They survive because removing them feels like reducing coverage, and coverage is what gets measured.

There is usually a story attached, too. The rule was written after an incident. It was requested by an auditor. A vendor shipped it enabled by default and nobody is sure what disabling it implies. Each individual rule has a reason to stay, and the sum of those reasons is a queue nobody trusts.

The uncomfortable observation is that a detection with a very low true-positive rate is not neutral. It is not “extra safety at the cost of some time”. It actively degrades the detections around it, because it consumes the attention that the good ones need and it teaches dismissal as a default posture. A rule that fires two hundred times a month and has never once been actionable is doing harm, and the correct action is to delete it or rewrite it — not to leave it running while everyone learns to ignore it.

Tuning is context, not thresholds

The instinct when a rule is noisy is to raise a threshold. Sometimes that works. More often it converts a rule that fires constantly into a rule that fires rarely and still means nothing, which is worse, because now nobody has enough exposure to it to judge.

The higher-value adjustments are usually contextual:

Whose behaviour is it? The same command executed by a build agent and by a finance workstation are different events. If the rule cannot distinguish them, it is missing the input that makes it useful.

Is it new? Much of what looks suspicious is simply unfamiliar. Something that has run on that host every weeknight for a year is a weak signal; the same thing appearing for the first time on a host that has never done it is a strong one. Baselining converts a static rule into a comparative one.

Does it stand alone? A single moderately suspicious action is often nothing. The same action following an unusual authentication, on a host that just made an unexpected outbound connection, is a sequence. Correlating raises precision far more reliably than tightening any individual threshold.

Closing the loop

The reason tuning stalls in most teams is that nobody feeds outcomes back. An analyst closes an alert as a false positive, the disposition is recorded somewhere, and nothing consumes that record.

Making it consumable is not complicated. For each rule, over a rolling window: how many times it fired, how many closures were true positives, and which entities generated most of the volume. That single view usually reveals that a small number of rules produce most of the noise, and that a handful of hosts or accounts produce most of their noise. Both are addressable in an afternoon.

The harder discipline is the decision rule that follows: if something has been firing for a quarter with no true positives and no plausible story for why the next one would be different, it goes. Not muted. Removed, with the rationale written down so that the next person does not rebuild it.

What good looks like

A queue that gets read carefully because reading it carefully is usually justified. Analysts who investigate rather than dismiss, because the prior probability that an alert means something is high enough to make investigation rational.

That state is reached by deleting things. It is unpopular, it looks like regression on a coverage dashboard, and it is the only route to a detection capability that functions when it matters.