The alert queue nobody works

Spend an hour reading what security practitioners write to each other on Reddit rather than what vendors write about them, and a single theme dominates. Not sophisticated adversaries. Not zero days. The queue.

Four hundred alerts today. Most of them false. The same three noisy rules nobody is allowed to turn off because a manager once asked for them. A backlog that was already unreachable on Monday morning, growing all week, with the quiet understanding that nobody will ever get to the bottom of it.

A survey of around 900 security professionals across the United States, United Kingdom and Europe found roughly 63% reporting burnout, attributed to workload, budget pressure and difficulty hiring. That number gets quoted as a wellbeing statistic. It is also a security statistic, and the more important reading of the two.

Alert volume is a control failure, not a workload problem

Here is the part that gets missed in the conversation about analyst wellbeing, which is a real and worthy conversation on its own terms.

A queue nobody can work is not a slow control. It is an absent one.

If your detection pipeline produces more items per day than your team can triage, then whether a given intrusion is caught is decided by where it happened to land in the queue. That is not detection. That is a lottery you are paying a licence fee to run.

Worse, the failure is invisible from above. The dashboard shows healthy alert volume, coverage looks broad, the tooling reports fine. Everything says the control is operating. The only person who knows it is not is the analyst who stopped reading past the first page months ago, and that person has learned there is no advantage in saying so.

A detection nobody triages is not a detection. It is a record you will read after the incident, while explaining why nobody acted on it.

Where the volume actually comes from

Almost never from too much coverage. Usually from four habits.

Rules imported wholesale. A new platform arrives with a thousand built in detections and they all get enabled, because turning things off feels like reducing security. Most were written against a generic environment that is not yours.

Nobody is allowed to tune. Somewhere in the organisation is a belief that suppressing an alert is negligence. So noise accumulates permanently, because the only safe action is to add.

Detections with no defined response. An alert that fires with nothing an analyst is empowered to do is pure cost. It gets read, it gets closed, and the reading of it is the entire expense.

Tool sprawl. Every product ships its own console and its own alerting, and the aggregate is a volume nobody chose. Gartner has estimated large enterprises run around 45 security tools, and research from IBM's Institute for Business Value and Palo Alto Networks has put the figure closer to 83 products across roughly 30 vendors. Nobody designed that. It accumulated.

What works

Measure what you can actually clear. Count how many alerts your team can properly triage in a day, honestly, including the investigation that a real one demands. That number is your budget. Everything generated beyond it is theatre. This single measurement changes more conversations with leadership than any dashboard.

Make tuning a named responsibility. Somebody owns detection quality, with authority to disable a rule and a record of why. Frame it as detection engineering rather than as switching things off, because the second framing loses the argument every time.

Require a response for every detection. If nobody can say what an analyst should do when it fires, it is not ready to be enabled. This one rule prevents most future noise.

Enrich before it reaches a person. Most triage time goes on assembling context that a machine could have attached already. Which asset, who owns it, is it internet facing, has this fired before, what changed recently. This is genuinely good work for automation, and it is the part of the job analysts are happiest to lose.

Cover techniques, not products. Map what you detect to MITRE ATT&CK and you can see where you are thin rather than where you are loud. Teams usually discover they have six overlapping detections for one technique and nothing at all for another.

Where AI helps here, and where it does not

Every vendor in this space now sells an AI SOC. Some of it is real.

The enrichment and summarisation work is a genuinely good fit. Pulling indicators, assembling context, drafting a timeline, telling an analyst what is already known about an alert before they start. Reporting from N able and the broader industry commentary converge on the same finding, which is that machine assistance compresses analysis time substantially while human judgement remains necessary.

What does not work is letting it close things. An automated triage that dismisses an alert correctly ninety nine times out of a hundred sounds excellent and is the exact shape of the problem, because the hundredth arrives eighteen months later in a room where somebody asks who decided this was nothing. If the answer is that a model did, the organisation has no position.

This is the same line we draw everywhere, and we wrote it out in full in our position on AI in compliance work and again in who is accountable when an AI agent acts on its own. The reading is a good job for a machine. The deciding carries accountability, and accountability needs a name.

The retention problem is a security problem

An analyst who leaves takes the undocumented knowledge of your environment with them. Which alerts are always noise here. Which server behaves oddly for legitimate reasons. Which team deploys on Fridays. None of that is written down anywhere, and the next person rebuilds it over six months while detection quality quietly drops.

So the cost of burnout is not only humane. It is the repeated loss of the context that makes detection work at all. Organisations that treat analyst attention as their scarcest resource, rather than as something to be filled to capacity, tend to detect things earlier. That is not a wellbeing argument dressed up. It is the mechanism.

Where we stand

We think most organisations should build fewer detections and finish them. A detection is finished when it has an owner, a documented response, an enrichment path and a review date. Ten finished detections outperform a thousand enabled ones, and the difference shows up the first time something real happens.

Our SOC design and monitoring practice works this way deliberately, starting from log source prioritisation and response definition rather than from tooling, and SOC Command carries the operating side for teams who cannot staff a rota. Threat Intelligence Mapper exists for the same reason, ending its output at the one check worth running rather than adding another feed to read.

And because detection coverage is now something frameworks ask you to evidence, CyberNexus holds the record that the review happened and who accepted it, so the answer survives the analyst who leaves.

Start here

Count yesterday's alerts. Count how many a person actually investigated.

If the first number is much larger than the second, you already know what your queue is, and you can stop treating it as a staffing problem and start treating it as an engineering one.

Common questions

What is alert fatigue

The state where security analysts receive more alerts than they can meaningfully investigate, so triage becomes shallow or stops entirely. It matters because it converts a detection capability into a lottery without anything on a dashboard changing.

How many alerts should a SOC receive per day

There is no universal number. The useful figure is how many your team can genuinely investigate in a day, including real investigation time. Anything generated beyond that capacity is not improving detection.

Is it safe to disable a noisy detection rule

It is safer than leaving it firing unread. The risk is not in disabling a rule, it is in doing so without a record. Assign ownership of detection quality, require a written reason, and set a review date.

Can AI fix alert fatigue

It genuinely helps with enrichment, correlation and summarisation, which is where most triage time goes. Letting it close alerts autonomously replaces a visible workload problem with an invisible accountability one.

How do we reduce false positives

Stop importing rule packs wholesale, tune against your own environment, require a defined response for every enabled detection, and map coverage to MITRE ATT&CK so you can see where you are thin rather than only where you are loud.