Alert Fatigue Is a Design Failure, Not an Analyst Failure
When an analyst misses a real incident buried in a flood of low-value alerts, the post-mortem reflex is to look at the analyst — attention, training, process discipline. That reflex is aimed at the wrong target. The flood is the problem, and the flood is a design choice made upstream by whoever built the alert pipeline. Alert fatigue is not a human-attention failure that better analysts would avoid; it is an engineering failure that better design would prevent.
This is about treating the alert pipeline as something to be engineered around the scarcest resource in any SOC — analyst attention — rather than something that accumulates by default until people drown.
The scarcest resource
Every SOC runs on a resource that does not scale: focused human attention. Analysts can meaningfully investigate a bounded number of alerts before quality degrades — not because they are weak, but because attention is finite and degrades under volume. This is a hard constraint, as real as compute or storage, and it is the constraint the alert pipeline must be designed around.
Alert fatigue is what happens when the pipeline ignores this constraint — when it emits more alerts than attention can absorb. The predictable result: analysts triage faster and shallower, develop reflexive dismissal of noisy alert types, and eventually miss the real thing because it arrived looking like the hundred false ones before it. None of that is an analyst defect. It is the rational human response to a pipeline that emits more than can be absorbed. Blaming the analyst is blaming gravity.
The design question is therefore not “how do we make analysts handle more alerts” — attention does not scale on command — but “how do we ensure what reaches an analyst is worth their attention.”
Why pipelines flood by default
Alert volume grows by default unless actively engineered against, for structural reasons:
Detections are added; they are rarely removed or tuned down. Each new detection adds volume. Few processes exist to retire or quiet detections that produce mostly noise. Volume ratchets upward — every project adds alerts, nothing subtracts them.
False positives are tolerated individually but compound collectively. Any single noisy detection seems acceptable — “it only fires a few extra times.” But a SOC runs hundreds of detections, and a few extra times each, multiplied, is the flood. The cost is invisible per-detection and overwhelming in aggregate. Nobody owns the sum.
Severity is assigned optimistically. Detections are often tuned to alert rather than to inform, and everything gets a severity that demands attention. When everything is important, nothing can be prioritised, and the analyst faces an undifferentiated wall.
“Just in case” alerting. The fear of missing something drives over-alerting — better to alert and be wrong than miss and be sorry, the reasoning goes. But over-alerting causes missing, by burying the real signal. The “just in case” instinct, unchecked, produces exactly the failure it tries to prevent.
The common thread: volume is everyone’s incidental contribution and no one’s owned responsibility, so it grows until people drown.
Designing for attention
The fixes are design disciplines, all oriented around respecting the attention budget:
Treat the attention budget as a hard constraint. Decide how many alerts your analysts can meaningfully investigate, and treat that as a ceiling the pipeline must respect — the way you would treat a compute or licensing ceiling. If the pipeline emits more than the budget, the pipeline is over-budget and must be tuned down, not the analysts asked to absorb more.
Make every alert earn its place. An alert reaching a human is a claim on the scarcest resource. It should clear a bar: is this actionable, is it worth a human’s attention, what would the analyst actually do with it? Alerts that fail this bar should inform (be logged, be queryable, feed correlation) without interrupting — the distinction between “an analyst must look at this now” and “this is recorded if needed” is the core design lever, and most pipelines collapse it.
Tune down as a first-class activity. Retiring and quieting noisy detections must be a tracked, ongoing activity with an owner — not something that happens reactively when complaints peak. The ratchet only turns one way unless someone is explicitly responsible for turning it back. Make noise-reduction a job, not an afterthought.
Differentiate severity ruthlessly. If everything is high, nothing is. Severity must genuinely separate “drop everything” from “look when you can” from “informational” — and that separation must be defended against the drift toward marking everything important. Ruthless differentiation is what lets an analyst’s attention land where it matters.
Add context to reduce investigation cost. An alert that arrives enriched — with the context an analyst would otherwise gather manually — costs less attention to triage. Enrichment is not just nice; it is a way to fit more real investigation into the same attention budget by lowering the per-alert cost. The same move that improves detection accuracy (context) improves alert economics.
The connection to detection quality
This ties directly to the behavioural-detection tradeoff: sensitive detection catches more threats and more false positives, and the false positives are paid for in analyst attention. So alert-pipeline design and detection tuning are the same problem viewed from two ends. A detection tuned without regard for its alert volume is externalising its cost onto the analyst — generating attention-debt that someone else pays at 3am.
The discipline that unifies them: every detection’s sensitivity choice is also an alert-budget choice, and both must be made with the analyst’s finite attention in view. You cannot tune detections in isolation from their alert cost, because the alert cost is where the detection’s downside actually lands.
The takeaway
When analysts miss the real thing in a flood of noise, fix the flood, not the analyst. Alert fatigue is a design failure — the predictable result of a pipeline that emits more than finite human attention can absorb, built up by a ratchet that adds alerts and never subtracts them. The flood is engineered, which means it can be engineered away.
The reframe to carry: analyst attention is the scarcest resource in the SOC, every alert is a claim on it, and a pipeline that respects that budget is a design choice you have to make deliberately — because by default, volume grows until people drown. The analyst who missed the alert was not weak. The pipeline that buried it was badly designed.
An independent piece by johlem.net — IT security, Luxembourg. SOC operations and alert-pipeline design for regulated finance.