Alert fatigue is an arithmetic problem, not a morale problem
Alert fatigue is three numbers — alerts arriving, minutes a real triage takes, analyst-hours in a week. Why hiring and tuning both lose to it, and the one term that brings the backlog down.
Alert fatigue is usually described as a morale problem, one step short of burnout: good analysts worn down, attention dulled, someone handing in their notice. Described that way, it invites morale answers — rotation, wellbeing, a nicer console. None of them move the number, because alert fatigue is arithmetic. Three quantities decide whether a queue is workable, and once they stop balancing, no amount of caring closes the gap.
The useful version of the question is not "how do we make this less exhausting?" It is "what is the shortfall in hours, and which term in the sum can be changed?" Answer that honestly and two of the industry's standard responses — hire more analysts, tune more rules — turn out to lose on the maths, while a third one wins for a reason that has nothing to do with effort.
The three numbers behind alert fatigue
Everything about alert fatigue reduces to these, and you can fill them in for your own SOC this afternoon.
| The number | Where it comes from | How it behaves |
|---|---|---|
| Alerts that reach a person, per week | your detection stack, after whatever deduplication and noise suppression you already run | grows with the estate, the sources and the rule set |
| Minutes a genuine triage takes | pivoting between consoles, checking the asset, reading the history | roughly fixed, and stubbornly so |
| Analyst-hours available, per week | headcount, minus the on-call rota, meetings, projects, holiday | grows slowly, in whole people |
Multiply the first two. Compare with the third. Say four hundred alerts in a week, at a quarter of an hour each — those are your numbers to fill in, not ours to claim — and that is a hundred hours of triage. A four-person team that also runs a rota, attends meetings and does project work does not have a hundred hours, and the shortfall is not a feeling. It is a number.
That shortfall never disappears. It relocates. It becomes alerts closed without being read, a queue worked newest-first because recency is the only order a tired person can hold in their head, and a backlog everyone has quietly agreed not to mention, handed on at every shift handover.
In the rows nobody opens, an intrusion's dwell time is still running. Threat hunting is the first thing to stop, because it is the only work with no queue behind it. Fatigue is the symptom your people report. The arithmetic is the cause.
Why hiring loses the arithmetic
Hiring adds to the third number, and it is the slowest, most expensive term to move. The SANS SOC Survey 2025 found that the most common fully staffed SOC is between two and ten people, and that 79% of SOCs run around the clock. At the low end of that range a 24/7 on-call rota consumes the entire team before a single alert is triaged — coverage is the constraint, not tier 1 triage capacity, and the next hire lands on the rota rather than in the queue.
There is a second effect that makes the sum worse before it gets better. A new tier 1 analyst is trained by your tier 2s, so the first months cost hours from the people already short of them. Meanwhile the first number keeps climbing on its own: every new source, every new detection pack, every acquisition adds arrivals without asking permission.
Hiring is addition against something that compounds. It is worth doing when you can afford it, and it will not close the gap on its own. This is the same arithmetic we set out in how a small SOC does the work of a large one, from the staffing side rather than the queue side.
Why tuning loses too, and why it still matters
Tuning attacks the right term — it lowers arrivals, which is the number multiplied by the other two — so it is the cheapest lever in the building and you should keep pulling it. A rule that fires a hundred times a week for a known-benign backup job is an hour of somebody's life, and turning it off is an hour recovered.
But it is bounded, and it is in direct competition with your coverage. CardinalOps read live production SIEM configuration metadata for its 2025 State of SIEM Detection Risk and found detections for 21% of MITRE ATT&CK techniques where the data already ingested could support 90%, with 13% of the rules that did exist silently broken.
Read that alongside the arithmetic and the bind is obvious: the honest response to 21% coverage is detection engineering — writing more rules — and every rule you add pushes the first number up. An hour spent suppressing noise is an hour not spent closing that gap, and the two jobs pull in opposite directions.
Tuning also decays. A suppression is a decision recorded against an estate that then changes. Hosts get rebuilt, a service moves, the thing you silenced last spring is no longer the thing that fires — and the silence is now covering something you would want to see. Tuning is maintenance work with a half-life, not a fix that stays fixed.
So keep tuning. Just stop expecting it to be the answer, because it works one rule at a time while the arithmetic is about the whole queue.
The only term that divides
Here is the term everybody misses. The workload is not the number of alerts. It is the number of distinct decisions a person has to make.
Ten alerts describing one intrusion are ten triages if a human meets them one at a time, and one triage if something joined them before anyone opened the first. Same telemetry, same detections, an order of magnitude of difference in hours. That join is the only lever in the sum that divides rather than adds or subtracts.
Deduplication is not the same lever. It drops repeats of the same alert; the join puts different alerts about one intrusion into one case — and only the second one brings the decision count down.
Today, in most SOCs, the join happens by hand and late — an analyst recognising the same host name in three consoles and deciding from memory whether the alerts belong together. Microsoft and Omdia's vendor-commissioned State of the SOC study in 2026 found that two thirds of SOC teams lose about a fifth of their weekly capacity to manual correlation. That fifth is not investigation. It is the join, performed repeatedly, by people, after the alerts have already been opened separately and counted separately.
Move the join in front of the human and the arithmetic changes shape. The arrival rate stays exactly where it was; the decision count collapses.
What it looks like when the join happens first
That is the job of a decision layer sitting above the detection stack you already run — open-source stacks such as ClickHouse, Elastic, OpenSearch or Wazuh, or market platforms such as Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender, SentinelOne and Cortex XDR, with a connector we build if yours is missing. Seculogik does not replace your sensors or your log store. It reads what they produce and decides which alerts are the same incident before a person opens any of them: alerts → cases → decisions.
Three properties matter to the sum:
- Nine independent checks have to agree on one verdict, so a case arrives with a confidence score and a written reason rather than a label, and the Correlation Engine writes down what mattered and what would have changed it.
- Bursts stop being backlog. Hundreds of low-severity repeats become one case rated for what the volume actually means, instead of hundreds of separate rows nobody will ever reach.
- The queue is ranked deterministically, with a clock and an owner, so the first thing your analyst opens is chosen by the facts of the case rather than by scroll position. That is the Verdict Layer.
The AI analyst in the SIROC module then works on what survives that join, and only on that. Gartner's formal position is that there will never be an autonomous SOC, and we agree with it. SIROC keeps a human in the loop: the machine proposes a verdict, a person decides, and anything destructive stops at an approval gate.
The measurement to run, and the one we will not fake
If you are evaluating anything on this basis, measure the right quantity. Not alerts shown, not events per second, not a dashboard with a falling line on it — and not MTTR on its own, which improves the moment a queue starts getting closed unread.
Count distinct decisions per week from your own telemetry, before and after, and time a triage in each state.
We publish no accuracy figure, no false-positive-reduction percentage and no time-saved multiplier of our own. There is no credible cross-vendor benchmark to anchor them to, and a number nobody can check is worth less than no number. We are pre-GA, we have no customers to point at, and we would rather you ran the sum on a week of your own alerts than believed ours.
The commercial model is built for exactly that test: priced per deployment, per year, with no meter on volume, on the endpoints you watch or on the customers you serve, so sending it more telemetry to find out never costs more.
Do all three, in this order
- Tune. Cheapest, immediate, bounded, and it decays — so budget for the maintenance and accept it will not scale.
- Join. The only term that divides. Do it before the human, not after, or you are paying analyst-hours to perform it manually.
- Hire. Last, and by then each new hour lands on a decision rather than on re-deriving what somebody already worked out on the previous shift.
Alert fatigue ends when the sum balances, and the sum balances when the decision count comes down. Everything else is treating the symptom.
Bring a week of your own alert volume to a demo and we will do the arithmetic with you — including the case where the numbers say you do not need us yet.