Most agile ceremonies look forward: planning the next sprint, refining the backlog, demoing what works. None of them ask how long a problem sat in production before somebody noticed it. That gap is exactly what mean time to detect is built to close.
MTTD measures the average time between an incident occurring and the moment the organization becomes aware of it. The arithmetic is simple. The discipline required to make the metric trustworthy is not.
What MTTD means and why it matters
MTTD** (mean time to detect, also called mean time to discover) tracks elapsed time from a production incident starting to someone noticing it. A low value signals healthy monitoring, alerting, and on-call practices. A high value means problems are rotting in production while customers suffer—and delivery teams stay unaware.
| Who benefits from low MTTD | Who loses when it's ignored |
|---|---|
| Customer-facing squads | Scrum masters blindsided by stakeholder complaints |
| On-call engineers with clear runbooks | Product owners facing steering committees unprepared |
| SRE teams with reliable leading indicators | Delivery teams planning work around invisible instability |
How to calculate MTTD
Sum every incident's detection time across a fixed window, then divide by the number of incidents. For example: five incidents with detection times totaling 257 minutes yields MTTD of 51.4 minutes.
The arithmetic is straightforward. The discipline is not. You need consistent timestamps for "incident started" and "first detected"—both of which must survive a chaotic production event. Without that consistency, the metric is fiction.
Real teams will want to slice further. Group by severity so a paging outage on a checkout service does not average with a misspelled footer. Define your outlier policy upfront and write it down. Deciding two sprints later whether to include that 14-hour detection time will introduce inconsistency the metric cannot absorb.
How MTTD compares to other failure metrics
These four metrics are routinely confused:
- MTTD** — time until the team notices the incident
- MTTR** (mean time to recover) — time from detection until service is restored
- MTTF** (mean time to failure) — average run time of a non-repairable component before it fails
- MTBF** (mean time between failures) — average time between resolutions of a repairable component
The pair most teams actually need is MTTD and MTTR. MTTD is about visibility. MTTR is about response. If your MTTD is fine but MTTR is awful, you have a tooling or process problem. If MTTD is awful but MTTR is fine, you have a visibility problem. Separating them lets you diagnose correctly.
Best practices to keep MTTD low
1. Define "detected" in your runbook.** Vague definitions produce inconsistent data. Specify the exact condition that marks an incident as "detected"—first alert, first customer complaint, or first engineer noticing.
2. Automate alerting on critical paths.** Manual detection is slow and random. Automated alerts on checkout flows, authentication endpoints, and core API paths compress detection time dramatically.
3. Tune alert thresholds together with the team.** Overly sensitive alerts breed fatigue. Too few alerts miss real incidents. This balance requires ongoing calibration, not a one-time setup.
4. Include detection in retrospectives.** When a bug is discovered late, that fact belongs in the retro, not just the incident report. Detection is a delivery outcome the team can improve.
5. Establish escalation clarity.** When an engineer spots a problem, they must know immediately who to contact and what access they need. Training on processes matters as much as training on tools.
What to watch next
MTTD tells you whether your monitoring and on-call culture actually work. Track it alongside MTTR, segment by severity, and put both numbers on the same dashboard the team reviews in sprint review. If the number stays high after two quarters, the problem is not tooling—it is ownership. Nobody has claimed detection as a delivery outcome. Fix that first, and the metric will move.
Key takeaways
- Calculate MTTD by summing incident detection times and dividing by incident count over a fixed window.
- Pair MTTD with MTTR to separate visibility problems from response problems.
- Define "detected" in your runbook before you trust the number.
- Automate alerting on critical paths and tune thresholds with the team.
- Bring detection into retrospectives so the delivery team owns it, not just ops.
Frequently asked questions
What does MTTD stand for?
MTTD stands for mean time to detect, sometimes called mean time to discover. It measures how long, on average, an organization takes to become aware of a production incident.
How do you calculate MTTD?
Add the detection time of every incident in the period, then divide by the number of incidents. For example: 257 total detection minutes across 5 incidents yields an MTTD of approximately 51.4 minutes.
What is the difference between MTTD and MTTR?
MTTD measures time until the team notices the incident. MTTR (mean time to recover) measures time from detection until service is restored. Together they separate visibility problems from response problems.
Should agile teams care about MTTD?
Yes. Detection time directly affects customer trust and is shaped by monitoring, alerting, and on-call practices that delivery teams own. Treating it as an ops-only concern hides a delivery competency from the people planning the work.
What are common pitfalls when adopting MTTD?
Inconsistent timestamps, mixing severities in one average, and letting outliers distort results. Define your outlier policy upfront, segment by severity, and write the detection definition into your runbook before collecting data.