MTTD and MTTR: Definitions, Formulas, and Examples

What are MTTD and MTTR?

Mean time to detect (MTTD) is the average time between the start of a security incident and the moment your organization identifies it. Mean time to respond (MTTR) is the average time from detection to a defined response milestone, such as containment, remediation, or service recovery.

Both are incident response metrics used to evaluate security operations performance. They can reveal whether delays occur in monitoring, investigation, escalation, containment, or recovery.

The term MTTR is ambiguous. Some teams use it to mean mean time to respond, while others use it to mean mean time to remediate or mean time to recover. Always state the exact starting point and endpoint when reporting it.

How to calculate MTTD and MTTR

Measuring MTTD and MTTR requires a reliable incident record with consistent timestamps. For each incident, collect at least:

1. Incident start time: When the malicious activity or operational failure began, if known.
2. Detection time: When a monitoring system, employee, customer, or analyst first identified the issue.
3. Acknowledgment time: When an assigned responder accepted responsibility.
4. Containment time: When the threat was stopped from spreading or causing further harm.
5. Recovery time: When affected systems and services returned to an approved operating state.
6. Closure time: When investigation, remediation, and documentation were complete.

The basic formulas are:

MTTD = sum(detection time - incident start time) / number of incidents

MTTR to contain =
sum(containment time - detection time) / number of incidents

MTTR to recover =
sum(recovery time - detection time) / number of incidents

The most important measurement decision is defining what “respond” means. Some teams use MTTR for detection-to-containment. Others use it for detection-to-recovery or detection-to-closure. These are different metrics and should not be combined under one label. If your organization uses several milestones, report them separately.

MTTD and MTTR example

Suppose three incidents have the following durations:

• Detection: 20, 40, and 60 minutes after the incidents began
• Containment: 30, 90, and 120 minutes after detection

The MTTD is:

(20 + 40 + 60) / 3 = 40 minutes

The mean time to contain is:

(30 + 90 + 120) / 3 = 80 minutes

Reporting these separately shows whether the larger delay is in monitoring and triage or in the response process itself.

Measure both alert-level and incident-level performance when useful. Alert-level MTTD can show how quickly analysts review actionable detections. Incident-level MTTD shows how quickly the organization discovers real security events, including incidents that were initially missed by automated tooling.

Technical requirements for reliable measurements

Your case management or SIEM platform should preserve immutable event timestamps and distinguish system-generated times from analyst-entered times. A simple data model might look like this:

incident_id
incident_start_at
detected_at
acknowledged_at
contained_at
recovered_at
closed_at
severity
detection_source
business_unit

A query for incident-level MTTD and containment time could follow this pattern:

SELECT
  AVG(EXTRACT(EPOCH FROM (detected_at - incident_start_at)) / 60)
    AS mttd_minutes,
  AVG(EXTRACT(EPOCH FROM (contained_at - detected_at)) / 60)
    AS mttr_containment_minutes
FROM incidents
WHERE incident_start_at >= '2026-01-01'
  AND incident_start_at < '2027-01-01'
  AND detected_at IS NOT NULL
  AND contained_at IS NOT NULL;

Exclude incomplete records from a finalized average, but track them separately. An incident that remains open should not silently disappear from reporting. Use a status such as pending, or calculate elapsed time through the current reporting period.

Also record the time zone and clock source used by each system. SIEM ingestion delays, endpoint clock drift, ticket edits, and manual backdating can produce inaccurate results. Normalize timestamps to UTC where possible, and retain the original event time for forensic review.

Mean, median, and percentile reporting

The mean alone can hide serious delays. Report the following together:

• Mean duration
• Median duration
• 90th or 95th percentile duration
• Incident count
• Results by severity
• Results by detection source
• Results by business unit or environment

A few unusually long incidents can raise the mean, while a high-severity incident hidden inside a favorable average can create a false sense of security. Percentiles help show the experience of slower cases that an average may conceal.

How to improve MTTD and MTTR

Use the metrics to identify process bottlenecks rather than treating them as simple scorecards:

• High MTTD: Improve logging coverage, alert quality, threat detection, sensor placement, or monitoring hours.
• Low MTTD but high containment time: Improve analyst access, escalation paths, playbooks, isolation capabilities, or decision authority.
• High closure time after containment: Improve root-cause analysis, eradication, documentation, and recovery procedures.
• Different results by severity: Review whether staffing and escalation rules match business impact.

Reducing MTTD often requires better visibility and more actionable alerts. For example, reviewing lessons from incidents such as an exploited Chrome zero-day and related critical vulnerabilities can help teams evaluate whether their detection sources and escalation rules cover relevant attack paths.

Reducing MTTR usually depends on preparation. Document response playbooks, test isolation procedures, maintain accurate asset inventories, and ensure responders can access the systems and credentials they need. An enterprise password manager such as 1Password can help centralize and control access to response credentials, provided it is configured with appropriate administrative safeguards.

Avoid using MTTD or MTTR as a simplistic individual performance score. Analysts may close tickets prematurely or downgrade incidents if the metric is tied directly to punishment or compensation. Measure quality, recurrence, scope, and business impact alongside speed.

Common MTTD and MTTR measurement mistakes

Changing the definition over time

If one quarter measures MTTR from detection to containment and the next measures it from detection to recovery, the results are not directly comparable. Record the definition with every report and preserve historical definitions when they change.

Mixing alerts and incidents

An alert is not necessarily an incident. Combining alert-level and incident-level records can make detection appear faster or slower than it is. Report them separately and explain how alerts are grouped into incidents.

Ignoring unknown incident start times

For many attacks, the exact start time is discovered only after investigation. Do not invent a precise timestamp. Mark the value as estimated, use a documented approximation, or report a separate metric based on the earliest confirmed malicious activity.

Excluding open incidents

Removing unresolved incidents from the average can make performance look better than it is. Track open cases separately and show how many records were incomplete at the time of reporting.

Reporting only the mean

The mean can conceal long-tail delays and high-severity outliers. Include medians, percentiles, counts, and severity breakdowns.

Treating speed as the only objective

A fast response that fails to contain the threat, preserve evidence, or prevent recurrence is not necessarily a successful response. Pair time-based metrics with outcome and quality measures.

When you’ll encounter MTTD and MTTR

You will encounter MTTD and MTTR in security operations center dashboards, managed detection and response reports, incident response programs, cyber insurance questionnaires, executive risk reporting, and security framework assessments.

These metrics are most useful when comparing your own performance over time. For example, a new endpoint detection rule may reduce MTTD, while better playbooks or automation may reduce containment time. Compare equivalent periods and similar incident types rather than treating every incident as interchangeable.

They can also support broader operational reviews. A security digest covering exploited Fortinet flaws, macOS malware, and other active threats may prompt teams to check whether their monitoring, triage, and containment procedures are prepared for current attack patterns.

Related terms

• Mean time to acknowledge (MTTA): Average time between alert creation and responder acknowledgment.
• Mean time to contain (MTTC): Average time between detection and effective containment.
• Mean time to recover: Average time between detection, containment, or outage start and restoration of normal service. Define the starting point explicitly.
• Mean time to remediate: Time required to eliminate the root cause or fix the exploited weakness. This is often different from containment.
• Time to detect (TTD): The duration for one incident, rather than the average across incidents.
• Time to respond (TTR): A general duration that may refer to acknowledgment, containment, remediation, or recovery.
• Dwell time: The period an attacker remains in an environment before detection or removal.
• Detection coverage: The proportion of relevant assets, techniques, or events that your controls can identify.

A useful reporting format names the exact metric and endpoint: MTTD from incident start to detection, MTTA from alert to acknowledgment, and MTTR from detection to containment. That precision makes the numbers comparable, actionable, and less likely to mislead.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.