MTTD Calculator
Break mean time to detect into dwell, telemetry lag, rule interval, queue delay and analyst confirmation, and find the bottleneck.
About MTTD Calculator
Halving the rule interval is the right adjustment for a scheduled search: if a rule runs every fifteen minutes, activity arrives uniformly across the window, so the expected wait is 7.5 minutes. Summing the phases makes it obvious whether MTTD is dominated by missing telemetry or by a slow pipeline. MTTD sets the ceiling on how much damage an intrusion can do, and the two fixes — more telemetry versus a faster pipeline — cost entirely different amounts, so knowing which phase dominates is what makes the metric actionable.
Formulas
MTTD
MTTD = pre-signal dwell + telemetry lag + (rule interval ÷ 2) + queue wait + analyst confirmation.
- pre-signal dwell
- Attacker time before touching instrumented ground
- rule interval ÷ 2
- Mean wait for the next scheduled run
- queue wait
- Time the alert sits before a human opens it
Dwell share
Dwell share = pre-signal dwell ÷ MTTD, which separates a telemetry gap from a pipeline problem.
- dwell share
- Portion of detection time you cannot fix with faster tooling
Worked example
With the default values below, MTTD Calculator returns Mean Time to Detect of 9.29. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Dwell before any signal is generatedaccepts 0–8,760 hours
- 8 hours
- Telemetry collection and shipping lagaccepts 0–1,440 minutes
- 5 minutes
- Scheduled rule intervalaccepts 0–1,440 minutes
- 15 minutes
- Alert queue wait before triageaccepts 0–10,080 minutes
- 40 minutes
- Analyst confirmation timeaccepts 0–1,440 minutes
- 25 minutes
- Benchmark dwell time to compare againstaccepts 1–1,000 days
- 194 days
Results
- Mean Time to Detect
- 9.29 hours
- MTTD as a Duration
- 9h 18m
- Detection Pipeline LatencyEverything after the attacker becomes visible.
- 77.5 minutes
- Share of MTTD That Is Pre-Signal Dwell
- 86.1%
- Slowest Phase
- Slowest phase: pre-signal dwell (480 min, 86.1% of MTTD)
- Faster Than Benchmark By
- 501.1 ×
Step by step
- 1Values used
- 2MTTD
- 3Dwell share
- 4Mean Time to Detect= 9.29 hours
- 5MTTD as a Duration= 557.50
- 6Detection Pipeline Latency= 77.5 minutes
- 7Share of MTTD That Is Pre-Signal Dwell= 86.1
- 8Slowest Phase= Slowest phase: pre-signal dwell (480 min, 86.1% of MTTD)
- 9Faster Than Benchmark By= 501.1 ×
Assumptions and limits
- The result is derived only from the 6 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
How is MTTD calculated?
MTTD = pre-signal dwell + telemetry lag + (rule interval ÷ 2) + queue wait + analyst confirmation. Halving the rule interval is the right adjustment for a scheduled search: if a rule runs every fifteen minutes, activity arrives uniformly across the window, so the expected wait is 7.5 minutes. Summing the phases makes it obvious whether MTTD is dominated by missing telemetry or by a slow pipeline.
Why does MTTD matter?
MTTD sets the ceiling on how much damage an intrusion can do, and the two fixes — more telemetry versus a faster pipeline — cost entirely different amounts, so knowing which phase dominates is what makes the metric actionable.
What values do I need to enter?
This calculator takes 6 inputs: Dwell before any signal is generated, Telemetry collection and shipping lag, Scheduled rule interval, Alert queue wait before triage, Analyst confirmation time, Benchmark dwell time to compare against. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why separate dwell from pipeline latency?
Because they have different owners. Pre-signal dwell shrinks by instrumenting more of the estate — identity, EDR, cloud control plane — while pipeline latency shrinks by shortening rule intervals, streaming instead of batching, and staffing the queue. Reporting one number hides which lever to pull.
How do I measure pre-signal dwell honestly?
From post-incident timelines: the gap between the earliest attacker action you can evidence and the first log entry that could have alerted. If forensics cannot reach the initial access, treat your figure as a lower bound and say so.