Mean time to detect

Most engineering teams don't know how long it takes them to find a production incident until they're already deep in a postmortem. Mean time to detect (MTTD) measures exactly that: the average time between when a failure occurs and when your team becomes aware of it. The shorter your MTTD, the less damage accumulates before anyone starts working on a fix. This page covers the definition, how to calculate it, published benchmarks, concrete ways to reduce it, and how DevStats surfaces the data you need to act.

TL;DR: Mean time to detect = total time to detect all incidents / number of incidents. Lower is better. Elite teams detect failures in under one hour.

Key takeaways

• Mean time to detect measures the average time between a failure occurring in production and your team's first awareness of it. It matters because every minute of undetected failure is a minute of user impact, revenue risk, and compounding technical damage your squad can't start addressing.
• MTTD is calculated by dividing the total detection time across all incidents by the number of incidents in a given period. DORA research consistently shows elite engineering teams detect failures in under one hour, while low-performing teams can take days.
• The most common mistake teams make with MTTD is confusing detection time with response time. If your alerting fires five minutes after an incident starts but no one acknowledges it for two hours, your effective MTTD is two hours, not five minutes. Alert coverage without on-call discipline doesn't move the number.
• DevStats surfaces DORA metrics including time-to-detect signals by connecting to your Git provider, CI/CD pipeline, and issue tracker, with benchmarks against 1,000+ engineering teams. Start a free trial to see your team's numbers in under two minutes.

Mean time to detect definition

Mean time to detect (MTTD) is the average time it takes for an engineering team to become aware of a failure after it has occurred in production. It measures the gap between when something breaks and when someone on the team knows about it.

Technically, MTTD is calculated as: MTTD = sum of all detection times / number of incidents. Detection time for a single incident starts at the moment the failure begins and ends when the team receives a confirmed alert or otherwise becomes aware of the problem. When viewed alongside the full suite of DORA metrics, MTTD gives engineering leaders a clear picture of their system's observability health and their squad's ability to contain the blast radius of any given incident.

Why mean time to detect matters for engineering teams

When MTTD is high, failures compound silently. Users hit errors, transactions fail, and data inconsistencies accumulate before anyone on the squad knows there's a problem. By the time an alert fires or a user complaint surfaces, the incident is already worse than it needed to be. Undetected failures also create misleading sprint data: your throughput numbers can look healthy while production is degraded.

MTTD connects directly to engineering leader KPIs. Slow detection extends incident duration, which inflates mean time to recover (MTTR), which damages SLA compliance and stakeholder trust. Teams with poor MTTD tend to spend more time in reactive firefighting and less time on planned work, which erodes planning accuracy over time. MTTD is one of the four key DORA metrics, sitting alongside deployment frequency, lead time for changes, and MTTR as a measure of software delivery stability.

Measuring MTTD is the first step. The data tells you where your observability gaps are. What you do about them is your call as the engineering leader.

How to measure mean time to detect

To calculate MTTD, you need a reliable timestamp for when each incident began and a second timestamp for when your team was first notified. The gap between those two points is the detection time for that incident. Average those gaps across a rolling window, typically 30 or 90 days, and you have your MTTD.

The data sources you need are your incident management tool (PagerDuty, OpsGenie, or equivalent), your monitoring platform (Datadog, Grafana, New Relic), and your deployment pipeline to correlate incidents with recent deploys. You can see how deploy frequency and incident patterns relate in DevStats's deploy feature. For cross-team benchmarking, DevStats's benchmarks feature lets you compare your MTTD against teams of similar size and release cadence.

No single authoritative published benchmark exists specifically for MTTD in isolation, but DORA's State of DevOps research (2023) groups teams by overall stability performance. The table below maps those groupings to qualitative MTTD ranges that align with published DORA findings.

Benchmarks vary by system complexity, team size, and release model. Use these as directional guides, not absolute targets.

Mean time to detect in practice: a real example

A VP of Engineering at a 45-person SaaS company noticed that their MTTR numbers were consistently high, but the postmortems kept pointing to the same root cause: the team was finding out about incidents from customer support tickets, not from their own alerting. They pulled three months of incident data and found their average MTTD was just over 18 hours. Most of those incidents were first reported by users.

The VP made two decisions: they assigned explicit on-call ownership for each service and added coverage to three under-monitored API endpoints that appeared repeatedly in the incident log. Within two sprints, average MTTD dropped below four hours. They tracked the change using their incident management tool alongside deployment data to confirm the improvement wasn't just a quieter period, but a real shift in detection capability.

How to improve mean time to detect

1. Audit your alert coverage against your incident history. Pull the last 20 incidents and check how each was first detected. If more than 30% were reported by users or found manually, you have an observability gap. Map those incidents back to specific services and add monitoring there first.
2. Define and enforce on-call acknowledgment SLAs. An alert that fires but isn't acknowledged for two hours is the same as no alert. Set a maximum acknowledgment time, track it, and review breaches in your next retrospective. This is a process fix, not a tooling fix.
3. Reduce alert noise before adding more alerts. High alert volume creates fatigue, and fatigued on-call engineers stop responding promptly. Audit your alerting rules and suppress or tune any alert that hasn't led to a real incident in the last 90 days. Fewer, higher-signal alerts reduce effective MTTD faster than adding more noise.
4. Correlate deploys with incident onset. Many incidents are triggered by a recent deployment. Connecting your CI/CD pipeline data to your incident log lets your squad identify the causal deploy faster, which shortens both MTTD and MTTR. This is where PR cycle time data becomes a useful leading indicator: faster, smaller PRs reduce the blast radius of any single deploy.
5. Review MTTD in sprint retrospectives, not just postmortems. Postmortems are reactive. Building MTTD into your regular sprint review cadence makes it a proactive signal rather than a lagging one.

Mean time to detect vs. mean time to recover

Mean time to detect and mean time to recover (MTTR) are both DORA stability metrics, but they measure different parts of the incident lifecycle. MTTD ends the moment your team knows about the problem. MTTR starts at that same moment and ends when the system is restored.

Use MTTD to assess how well your monitoring and on-call processes catch problems. Use MTTR to assess how well your squad resolves them once they're known.