Alert Volume and Review Capacity

A detection system produces candidates. A person converts candidates into findings. The number of candidates that person can genuinely examine is the ceiling on what the system can achieve, and it is almost never used as a design input.

Start from capacity

Measure how long a triage actually takes. Not the optimistic estimate. Time twenty real alerts end to end, including the context gathering. In most deployments it is between five and twenty minutes.

Multiply by the available hours. An analyst with other duties has perhaps three hours a day for queue work. At ten minutes each, that is eighteen alerts.

Subtract for investigations. A single escalation consumes a day, during which the queue is unreviewed.

The realistic figure for most organisations is single digits to low tens per day. Deployments configured for hundreds are not detecting more; they are dismissing faster.

What happens above capacity

The queue does not simply grow. Behaviour changes in specific, predictable ways.

Dismissal accelerates. Analysts develop heuristics for closing quickly, and the heuristics are based on surface features rather than substance.

The bottom is never reached. Whatever ordering exists, everything below the point where time ran out is unreviewed. If ordering is by score, and the interesting thing scored moderately, it is invisible.

Attention degrades within a session. Accuracy on the fortieth alert is not the accuracy on the fifth.

Adjudication quality falls. Categories get applied carelessly, which poisons the label set you were going to use for measurement.

Nobody reports it. Analysts adapt rather than escalate. The queue looks handled.

Making the queue smaller without losing detection

In order of value:

Correlate into entities or incidents. Twenty events from one action is one item. This alone frequently halves volume.

Suppress unqualified rarity. Require a second condition before surfacing.

Enrich. An alert that takes ten minutes because context is missing takes two when it is attached. This raises effective capacity without changing detection at all.

Exclude approved workflows explicitly and with expiry dates.

Retire detectors with no true positives over a rolling period.

Then, and only then, raise thresholds.

Tiering rather than a single queue

A single ranked list treats all candidates as equivalent. Tiering acknowledges they are not.

Automated handling. Some detections have a known, safe response — a notification to the entity, an automatic ticket, a logged record. Not everything needs a human.

Fast lane. High-precision, low-volume detectors with near-zero false positives — service account interactive logon, impossible travel, forwarding rule creation. Reviewed first, always.

Standard queue. Scored anomalies, reviewed to capacity.

Sampled tier. Everything below the review line, of which a random sample is examined. This is the only way to learn what you are missing, and it is the tier organisations cut first.

The sampled tier costs perhaps five percent of capacity and is the difference between knowing your blind spots and assuming you have none.

Measuring the right thing

Proportion of the queue reviewed. The single most important operational metric and one almost nobody reports.

Time from event to review. Detection that arrives three days later is of limited use during an active intrusion.

Precision per detector. Which ones are worth the attention they consume.

Dismissal rate by analyst. Large divergence between analysts means the criteria are unclear.

What the sampled tier found. If sampling regularly surfaces things the main queue missed, the ordering is wrong.

Measuring your actual capacity

Most teams estimate this and the estimate is optimistic by a factor of two or three.

Time twenty real triages end to end. Start when the analyst opens the alert, stop when it is closed with a category. Include the context gathering, the lookups, the conversation with a colleague.

Take the median, not the mean. A few long investigations distort the average.

Count the hours actually available. Subtract meetings, escalations, project work, leave and the other duties queue analysts invariably have.

Divide. The result is usually smaller than the current queue by a wide margin.

Then recheck during a busy week. Capacity during an incident is close to zero, and a queue sized for a good week is unreviewed for the fortnight that matters.

Publishing this number changes the conversation about thresholds from a preference to an arithmetic constraint.

Common false positives

The alerts that consume capacity without producing findings, which is what tiering and correlation are for:

Repeat entities whose structural explanation was established months ago but is not recorded anywhere persistent.

One action, many alerts, where correlation is absent.

Approved workflows that were never formally excluded.

Immature baselines producing deviation from insufficient history.

Known calendar effects.

Data pipeline artefacts.

A queue where these dominate is not a detection problem; it is a workflow problem, and raising thresholds addresses neither.

Blind spots and assumptions

That capacity is fixed. It varies with incidents, leave and other duties. A queue sized for a good week overflows in a bad one.

That the ordering is correct. It is the model's ordering, and the model does not know what matters to you.

That unreviewed means unimportant. It means nobody looked.

That adding an analyst doubles capacity. It adds capacity and adds inconsistency; calibration between analysts is work that has to be done deliberately.