Mean Time to Triage: Measure Queue Health, Not Speed

Mean time to triage is useful only when the start, stop, waiting time, and decision quality are defined. One average without those controls is a speedometer disconnected from the queue.

The problem is not a lack of SOC metrics. It is that teams collapse several different delays into one number, celebrate a falling mean, and miss the old alerts nobody finished. Fast closure can improve the chart while detection coverage, analyst trust, and attacker opportunity get worse.

Current ranking pages often mix mean time to triage with detection, acknowledgment, containment, or response. Many publish universal targets without a shared clock definition. Few show the slow tail, unfinished work, business hours, reopened cases, or the SQL behind the chart. This guide fixes that measurement problem.

What is mean time to triage?

Mean time to triage measures elapsed time from an alert entering the governed work queue to a recorded triage decision. That decision should state the disposition, evidence basis, priority, owner, and next route. A click on “acknowledge” is not enough unless acknowledgment is the defined end of triage.

Write the clock in plain language. Start when the platform accepts the alert after required normalization and grouping. Stop when a person or approved automation commits a reasoned outcome. Preserve source event time as a separate field because pipeline delay matters, but do not quietly move the start backward or forward when a vendor dashboard changes.

Mean time to triage sits inside the wider alert fatigue operating model. It measures one part of decision delivery. It cannot tell you whether the queue admitted the right work or whether the eventual action contained harm.

Which clocks should a SOC separate?

Split total triage time into queue wait, active review, evidence wait, and decision recording. Queue wait begins when the alert enters and ends when an owner starts work. Active review counts time spent examining evidence. Evidence wait covers delayed queries, data sources, or business owners. Decision time ends when the outcome and route are saved.

Each clock points to a different fix. Long queue wait suggests demand, staffing, schedule, or priority trouble. Long active review suggests weak context, poor runbooks, or complex detections. Evidence wait points to broken integrations or ownership. Slow decision recording may be a case management design problem.

Track automation separately. A machine decision in 20 seconds and a human decision in 20 minutes should not be averaged as if they handled equal cases. Segment by alert family, severity, source, shift, decision maker, disposition, and whether the case reopened.

Why does triage time matter now?

Triage speed matters because attacker time is uneven. The March 23, 2026 M-Trends release drew on more than 500,000 hours of Mandiant frontline investigations during 2025. It reported a global median dwell time of 14 days, up from 11 days, while cyber espionage and North Korean IT worker cases each had a 122 day median.

The same report found that organizations first detected malicious activity internally in 52 percent of 2025 investigations, up from 43 percent in 2024. It also reported that the median handoff from an initial access actor to a secondary group collapsed from more than eight hours in 2022 to 22 seconds in 2025.

Those figures do not create a universal 22 second triage target. They show why one target for every alert is lazy management. A low confidence policy alert and evidence of active privileged access have different useful decision windows. Set service levels by consequence, attack progress, and the action still available.

How do you calculate mean time to triage?

For each completed alert, subtract queue entry time from triage decision time. Add those durations and divide by the number completed in the period. If 600 alerts total 9,000 minutes, mean time to triage is 15 minutes.

That simple math has a trap. The 600 completed alerts exclude anything still waiting. If 80 old alerts remain open, the mean describes the work the team finished, not the full queue. Report the count and age of unfinished alerts beside it. Also publish how duplicates, reopened cases, and withdrawn alerts are handled.

Use calendar time for urgent lanes. For queues that operate only during business hours, publish both calendar and staffed time or make the schedule explicit. Pausing the clock overnight can be valid for a policy queue. It is misleading for a page that claims continuous response.

Why are p50 and p90 better than the mean alone?

The mean is sensitive to a few extreme cases. Median, or p50, shows the middle completed alert. The p90 shows a slow boundary: 90 percent finished at or below that duration, while 10 percent took longer. Together they reveal whether an improvement reached most alerts or only removed a handful of outliers.

Suppose ten alerts finish in 4, 5, 5, 6, 6, 7, 7, 8, 9, and 63 minutes. The mean is 12 minutes. The median is 6.5. One delayed case more than doubles the mean relative to the typical result. That outlier deserves analysis, but it should not define ordinary performance by itself.

Publish a distribution or a few stable percentiles, not twenty decorative numbers. Use p50 for the typical path, p90 or p95 for the slow tail, and maximum queue age for unfinished risk. Keep the count visible so a small sample cannot masquerade as a trend.

What SQL calculates triage time correctly?

The following PostgreSQL example groups completed alerts by severity and returns count, mean, p50, and p90. The official PostgreSQL aggregate documentation confirms that percentile_cont accepts interval values and uses theWITHIN GROUP order syntax.

WITH triage AS (
  SELECT alert_id, severity, triaged_at - created_at AS triage_time
  FROM security_alerts
  WHERE created_at >= CURRENT_DATE - INTERVAL '30 days'
    AND triaged_at IS NOT NULL
)
SELECT severity,
       COUNT(*) AS triaged_alerts,
       AVG(triage_time) AS mean_triage_time,
       percentile_cont(0.5) WITHIN GROUP (ORDER BY triage_time) AS p50_triage_time,
       percentile_cont(0.9) WITHIN GROUP (ORDER BY triage_time) AS p90_triage_time
FROM triage
GROUP BY severity
ORDER BY severity;

Adapt table and field names to the case system. Then add a separate query for open alert age using current time minus creation time. Do not insert the current time as a fake completion timestamp in the completed distribution. That mixes censored work with observed outcomes and makes the result hard to explain.

Which metrics belong beside mean time to triage?

Start with intake, completions, open count, maximum age, and age by priority. Those numbers expose whether the team is keeping up. Add active review minutes and evidence wait so leaders can see whether the constraint is capacity, context, or a broken dependency.

Next, measure decision quality: analyst override rate, reopened cases, disposition changes, false closure rate, incident contribution, and attack replay pass rate. Use the security signal to noise scorecard to keep useful action and tested coverage beside speed.

Finally, track fairness of service across lanes. A low overall mean can hide identity alerts waiting all day while a large automated family closes in seconds. Publish time and age by alert family and decision maker. The mix is part of the result.

How should leaders set a triage target?

Begin with the action window. Ask when delay removes a useful option, such as disabling a token before reuse, isolating an endpoint before spread, or contacting an owner before a change completes. Set the target inside that window with enough margin for investigation and response.

Then test capacity. If 900 alerts arrive per shift, 30 percent require review, and each review takes ten active minutes, demand is 2,700 minutes, or 45 analyst hours. A five person shift with six productive review hours each provides 30 hours. The target is impossible by 15 hours before meetings, breaks, and incidents.

Change intake, review cost, or staffed capacity. Do not turn the deficit into a harsher dashboard. Use alert prioritization to protect the cases where delay changes harm, then fix the alert families that consume the most avoidable minutes.

How do you improve mean time to triage?

Fix the largest clock, not the headline number. If queue wait dominates, reduce admissions, group duplicates, adjust schedules, and route by real ownership. If active review dominates, enrich the alert and write alert runbooks with exact evidence and branches.

When evidence wait dominates, measure failure and latency by integration. Cache safe context, repair entity resolution, and add explicit timeouts. Deep endpoint context with AI driven analysis can assemble and explain varied evidence, but missing sources must remain visible. Artemes AI follows that evidence centered approach.

Use automated alert triage for stable collection and bounded decisions. Run in shadow mode first. Measure net time recovered with overrides, reopened cases, and replay tests visible. A quicker wrong answer is negative capacity.

What should a triage dashboard show?

Put demand and service on the same screen. Show alerts admitted, decisions completed, work still open, net queue change, maximum age, and p50 and p90 time by lane. Add active review and evidence wait where those timestamps are reliable. A seven day trend is useful for shifts. A longer view shows whether a release or staffing change held.

Make denominators visible. “p90 improved 18 percent” means little without the number of alerts, mix of sources, share handled by automation, and any clock definition change. Mark outages and migrations. Let operators drill from a slow segment into alert families and reason codes instead of asking them to explain an executive average from memory.

Include one quality panel beside time: sampled false closures, analyst overrides, reopened alerts, and attack replay status. The dashboard should make gaming uncomfortable. If time falls because a source stopped sending, intake and coverage will expose it. If easy automation changes the mix, the human segment remains visible.

Which measurement mistakes corrupt the metric?

Changing the clock definition without backfilling history creates a false trend. So does excluding weekends, merged alerts, automated closures, or one source without marking the break. Put definition version and system changes on the chart.

Means across unlike work are another problem. A phishing report, cloud control alert, endpoint process alert, and active identity incident have different evidence and urgency. Aggregate for executive capacity, but keep the segments that operators can act on.

The worst mistake is rewarding closure speed alone. Analysts will learn to choose the fastest disposition, automation will target easy volume, and old ambiguous cases will remain. Pair every speed target with queue age and a quality guardrail.

Frequently asked questions

What is a good mean time to triage?

There is no universal target. Set one by alert lane using attacker progress, business consequence, available response, evidence cost, and real capacity. Publish the clock definition with the result.

Is mean time to triage the same as MTTD?

No. Mean time to detect measures delay before detection. Mean time to triage begins when an alert enters the governed queue and ends with a decision and route. Keep the clocks separate.

Should automated closures count?

Yes, in a separate segment. Show volume, duration, rule family, sampled quality, overrides, and reopened cases. Mixing machine and human decisions can hide the work people still face.

Why report median if the metric is called mean time?

Keep the named mean for continuity, but publish median and a slow percentile because the distribution is usually skewed. The three numbers answer different operating questions.

Executive takeaway

Freeze the clock definition before setting a target. Separate queue wait, active review, evidence wait, and decision time. Publish mean, p50, p90, unfinished queue age, and one quality guardrail by alert family. Then fix the clock that consumes the most avoidable time. Mean time to triage should expose the operating constraint, not hide it inside one flattering average.