skip to content

Median time-to-close falls each week as your alert backlog grows - improvement or clearing?

level: seniorimportance: should knowfreq 44%

answer

  1. compare like with like
  2. hold the case mix constant
  3. note length, bulk closes, queue depth
  4. speed tracking backlog, not tooling
  5. blind re-review the fastest closes

basics

~20 s

Falling close time is good news only if you can point at the change that caused it. Compare within one rule and severity, not across the mix, then settle it by blind re-reviewing a sample weighted to the fastest closures.

solid answer

~50 s

Treat it as unexplained until proven otherwise. There are honest explanations - an enrichment step that now attaches the answer to the alert, a rewritten playbook, or a mix shift where a chatty new rule floods the queue with genuinely trivial cases and drags the median down. Rule those out by holding the mix constant: compare seconds-to-close within the same rule and severity, week over week, rather than across everything. Then look at the case system's own audit trail - note length, bulk closes where one analyst clears many cases in seconds, and whether close speed tracks queue depth at the hour of close rather than any tooling change. Correlation with backlog is the tell, because getting faster when there is more to do is not how investigation works. The decisive step is a blind re-review of a sample over-weighted to the fastest closes.

code

json · 11 lines
json
[
  {"case_id":"C-84120","rule":"suspicious_service_install","disposition":"false_positive",
   "closed_at":"2026-03-11T02:41:07Z","seconds_to_close":38,"note_chars":11,"queue_depth_at_close":412},
  {"case_id":"C-84121","rule":"suspicious_service_install","disposition":"false_positive",
   "closed_at":"2026-03-11T02:41:52Z","seconds_to_close":41,"note_chars":11,"queue_depth_at_close":411},
  {"case_id":"C-84122","rule":"k8s_exec_into_pod","disposition":"benign_true_positive",
   "closed_at":"2026-03-11T02:44:19Z","seconds_to_close":96,"note_chars":14,"queue_depth_at_close":409},
  {"case_id":"C-79004","rule":"k8s_exec_into_pod","disposition":"benign_true_positive",
   "closed_at":"2026-02-04T14:02:55Z","seconds_to_close":1140,"note_chars":486,"queue_depth_at_close":37}
  ...
]

go deeper

for a junior

Know that closing faster is not the same as deciding better, and that a queue getting deeper is a reason to be suspicious of a falling close time rather than pleased by it.

for a middle

Explain the confounders - a mix shift from a new noisy rule, an enrichment or auto-close deployment - and how comparing within a single rule and severity separates them from a behaviour change.

for a senior

Show the full sequence: rule out benign causes, read the case system's audit trail for note length, bulk closes and queue depth, then settle it with a blind re-review weighted to the fastest closures.

for a principal

Own the incentive: a speed metric published without a paired verdict-quality measure creates the behaviour it then detects, and the fix is upstream content and expectations rather than instructions to work slower.

## What the metric is and why it drifts Median time-to-close is read off the case management system's own audit trail - the closure timestamps, who closed each case, the disposition and the note. It is popular because it is free and it moves. It is dangerous for the same reason: it is a **throughput** measure being used as a proxy for **quality**, and the fastest way to improve it is to stop investigating. The pattern that should stop you is the correlation. If close time fell in the same weeks the backlog grew, the two are almost certainly the same event: the queue got deeper, pressure to clear it rose, and the time spent per case fell. Cases do not become easier because there are more of them. ## The benign explanations, checked first Before concluding anything, rule out three real ones: 1. **A tooling change.** An enrichment step now resolves the entity, attaches the account's normal behaviour, or pulls the change record - so an analyst genuinely needs less time. This is verifiable: it has a deployment date, and the improvement should appear as a step at that date, not a slow slide. 2. **A playbook or automation change.** A verified condition is now auto-closed, or a playbook was rewritten to end earlier for a specific rule. 3. **A mix shift.** This is the subtle one. A newly deployed noisy rule can add thousands of genuinely trivial cases and pull the overall median down while every individual rule's close time is flat or rising. The aggregate moved without any analyst changing behaviour. Mix shift is why the first analytical move is always **compare like with like**: seconds-to-close within a single rule and severity band, week over week. If the fall survives that, it is about how cases are being worked. ## Reading the audit trail The case system records more than duration, and the extra fields are what turn a suspicion into a sample: - **Note length.** An eleven-character note is not, on its own, proof of anything - some closures are legitimately one line when enrichment already carries the evidence. It is a *sampling signal*: it tells you which cases to re-review, never what the verdict should have been. - **Bulk closure patterns.** A run of cases closed by one account within seconds of each other, all on one rule, is a multi-select clear rather than a sequence of judgments. - **Queue depth at the moment of close.** If seconds-to-close falls as depth rises, within the same rule, you have the correlation stated plainly. - **Disposition mix.** If the share of cases closed without escalation rises at the same time, the pressure is being paid for in verdicts. ## The decisive test None of the above proves a wrong verdict; they only locate where to look. The test is a **blind re-review**: draw a sample over-weighted toward the fastest closures, strip the disposition and notes, have a different analyst work them from the raw evidence, and compare. - If the re-review agrees, the queue really did get easier and you now have evidence to say so. - If it does not, you have something far more useful than an opinion: a measured disagreement rate on exactly the cases the speed metric was celebrating, plus concrete examples of what was missed. ## What you do with the answer If the verdicts held up, publish the finding and the mechanism - the enrichment, the playbook, the mix - so nobody claims credit for an improvement that was a chatty rule. If they did not, the fix is rarely "work slower". It is upstream: the rule producing the flood, the missing context that made each case expensive, the auto-close that should exist for a verified condition, and the expectation that the queue must be emptied every shift regardless of what is in it. Reporting close time without a paired quality measure creates the pressure by itself; the corrective is to publish the two together, so speed cannot be improved by degrading verdicts without the second number moving. ## The security-specific stake In a reliability context a slow queue is an annoyance. Here, the cases being cleared fastest are the ones an intruder is hiding in - and the whole point of the behaviour they are using is that at a glance it looks like administration. A metric that rewards the glance is a metric an adversary benefits from.

  • Which explanation would make a falling close time genuinely good news?
    One you can point at with a date: an enrichment step that now attaches the deciding evidence, an auto-close for a verified condition, or a rewritten playbook. The improvement should appear as a step at that deployment, show up inside a single rule rather than only in the overall mix, and survive a blind re-review of the faster cases.
  • What does an eleven-character case note tell you on its own?
    Nothing conclusive. Some closures are legitimately one line because enrichment already carried the evidence. Note length is a sampling signal - it tells you which cases to pull into a blind re-review - and only becomes evidence about verdict quality once those cases have been re-worked independently.
  • How could a mix shift drag the median down while every analyst is working more slowly?
    A newly deployed noisy rule can add thousands of trivial cases that close in seconds. The aggregate median follows that volume even as the per-rule close time on everything else rises. That is why the first cut is always within a rule and severity band rather than across the whole queue.

A call centre whose average handle time drops during its busiest hour has not become better at answering questions.

saying these in an interview costs you the question

  • Reporting falling close time as a productivity win
  • Comparing medians across a changed case mix
  • Treating short notes as proof of a wrong verdict
  • Telling analysts to slow down instead of fixing upstream
  • Publishing close time with no paired quality measure

context