The security operations center reporting stack has converged on a small set of headline metrics — MTTD (mean time to detect), MTTR (mean time to respond), and alert volume — that are easy to measure and poor predictors of actual SOC health. MTTD in particular has a structural flaw: it measures the gap between attack occurrence and detection, not the gap between detection and analyst disposition. A SOC with a full alert backlog can still report a low MTTD because the detection rules fire correctly; the problem is that no one is acting on the detections. The metric looks fine while the backlog grows.
Why MTTD Is Insufficient
MTTD measures when a detection rule fires relative to when the attack began. It captures detection coverage quality — whether your rules catch attacks within an acceptable timeframe. It does not capture analyst throughput, enrichment pipeline speed, or the operational reality of how quickly detected alerts are actually triaged. A SIEM that correctly detects a ransomware precursor activity within 2 minutes of occurrence reports excellent MTTD. If that alert sits in an unreviewed queue for 6 hours because the analyst team is overwhelmed, the 2-minute MTTD is operationally meaningless.
The metric that MTTD reporting frequently obscures is queue age distribution — how long alerts sit between being generated and receiving their first analyst touch. Queue age is the direct operational consequence of alert fatigue. An analyst team that cannot keep pace with incoming alert volume accumulates a backlog, and the backlog ages. Alerts in the backlog from 4 hours ago are less actionable than alerts from 10 minutes ago because the attacker has had more time to progress through the kill chain.
The Metrics Set That Reflects Analyst Load
A more complete SOC operational health reporting stack includes five metrics that individually measure different dimensions of analyst capacity and collectively give a realistic picture of SOC throughput:
Alert queue age P50/P90/P99: The 50th, 90th, and 99th percentile ages of alerts currently in the queue (time since generation, not time since last action). P50 reflects normal processing speed; P90 shows how far behind the queue gets under moderate load; P99 identifies the worst-case stale alerts that have been sitting untouched. A healthy SOC has P99 queue age under 4 hours for high-severity alerts and under 24 hours for medium-severity. When P90 exceeds 2 hours for high-severity alerts, the team is behind.
Mean time to enrich (MTTE): The average time between alert generation and completion of IOC enrichment for all indicators in the alert. This metric isolates the enrichment pipeline contribution to overall response delay. If MTTR is high but MTTE is low, the bottleneck is in analyst decision-making or response coordination, not enrichment. If MTTE is high, the enrichment pipeline needs attention. ThreatPulsar's analyst workload dashboard exposes MTTE as a first-class metric specifically because it is not captured in standard SIEM reporting.
Alert disposition rate per analyst-hour: How many alerts per analyst-hour of shift time are receiving a disposition decision (escalate, close, investigate). This is the core throughput metric for analyst capacity. Dividing daily alert volume by the product of analyst count and shift hours gives a per-analyst-hour target; comparing actual disposition rate against target shows whether the team is keeping pace or accumulating backlog. A team falling below their target disposition rate for more than 2 consecutive hours is accumulating a backlog that will require overtime or triage shortcuts to clear.
False positive rate by rule and alert type: The percentage of alerts from each detection rule that receive a "benign / false positive" disposition. False positive rate is a detection rule quality metric, not strictly an analyst load metric, but it directly affects analyst load: every false positive consumes triage time that could be spent on real threats. A detection rule with a 40% false positive rate is costing the team 40% of the time they spend on it, contributing to backlog accumulation. Rules with false positive rates above 20% should be tuning candidates.
Enrichment coverage rate: The percentage of alerts where enrichment returns at least one result with context above a minimum confidence threshold. Low enrichment coverage (below 70%) indicates either that the IOC types being generated are not covered by current feeds, or that the enrichment service has coverage gaps in the threat actor sectors active against the organization. Enrichment coverage rate below 70% means analysts are making triage decisions without context on a significant fraction of alerts, which degrades decision quality and increases false negative risk.
Operationalizing the Metrics in Dashboard Form
The five metrics above require data from multiple sources: SIEM event timestamps (for queue age calculation), enrichment platform API response timestamps (for MTTE), SOAR case management disposition records (for disposition rate and false positive rate), and enrichment platform coverage reports (for enrichment coverage rate). Assembling them into a single operational dashboard typically requires a data aggregation layer — either a custom SIEM query set or a purpose-built SOC metrics dashboard that pulls from multiple API sources.
ThreatPulsar's analyst workload dashboard provides MTTE and enrichment coverage rate natively. Queue age distribution and disposition rate require data from the SIEM/SOAR layer and are typically integrated via the ThreatPulsar REST API, which accepts metric pushes from SOAR platforms and SIEM webhooks. The combined dashboard gives shift supervisors a real-time view of analyst load that is not available from any single platform's native reporting.
The operational use case for the combined dashboard is shift-level load balancing: when queue age P90 exceeds the threshold during a shift, the supervisor can identify whether the bottleneck is enrichment latency (MTTE is high), false positive volume (false positive rate is elevated on a specific rule), or pure alert volume (disposition rate is on target but incoming volume exceeds team capacity). Each diagnosis leads to a different intervention.
The Alert Volume Trap
Alert volume as a headline metric creates perverse incentives. Teams that are evaluated on maintaining low alert volume have an incentive to tune detection rules more aggressively than the risk environment warrants — raising thresholds, narrowing scope — to keep the volume number manageable rather than addressing the underlying throughput constraint. The result is lower alert volume with higher false negative rate: fewer alerts, but a higher percentage of real attacks going undetected.
Alert volume is a useful operational input — it tells you when to expect workload spikes, and it informs team sizing decisions. It is not a useful performance metric because it can be optimized in ways that reduce security effectiveness. A more useful volume metric is the ratio of alerts to confirmed true positives: what percentage of the alerts generated last month were genuine threats? This ratio measures detection precision and guides rule tuning in a direction that improves detection quality rather than simply suppresses volume.
Connecting Metrics to SOC Investment Decisions
The metrics framework above changes how SOC investment decisions are analyzed. The question "should we hire an additional analyst?" is answerable with quantitative data when you have disposition rate per analyst-hour and queue age distribution: if the team is running at full disposition rate and queue age P90 is still above threshold, the bottleneck is headcount and additional analysts will directly reduce queue age. If the team's disposition rate is below target and queue age is acceptable, the bottleneck may be analyst process efficiency (enrichment tooling, playbook quality) rather than headcount — additional analysts won't fully solve that problem.
As we discussed in our article on why manual IOC enrichment fails at scale, the enrichment bottleneck is architectural, not a staffing problem. The metrics framework makes this argument quantitative: when MTTE accounts for 60% of the total time between alert generation and disposition decision, enrichment automation reduces MTTR by up to 60% without any headcount increase. That is a more precise investment justification than generic claims about analyst productivity.
Conclusion
Alert fatigue is a measurable operational condition, not a subjective analyst experience. The metrics that measure it — queue age distribution, MTTE, disposition rate, false positive rate by rule, and enrichment coverage rate — are computable from existing data in the SIEM, SOAR, and enrichment platform layers. Assembling them into a coherent operational dashboard requires some integration work, but the visibility payback is significant: shift supervisors can diagnose bottlenecks in real time rather than inferring them from analyst burnout surveys after the fact.
The goal of SOC metrics is not to produce numbers for quarterly reporting; it is to make the operational state of the team legible in real time, so that the right interventions can be applied before a backlog becomes a missed detection becomes a breach.