MTTD (Mean Time to Detect)

What is MTTD (Mean Time to Detect)?

MTTD (Mean Time to Detect) is the average time it takes to notice that something is wrong. The clock starts when a failure begins to affect the system, for example when error rates rise after a bad deploy, and stops when the incident is detected: an alert fires, a synthetic check fails or a customer opens a ticket. MTTD is the earliest phase of the incident lifecycle and sets a floor for everything that follows. A problem that nobody sees cannot be diagnosed, mitigated or fixed.

MTTD is usually reported together with MTTR. Detection time is part of total resolution time, so improving detection shortens the whole incident, often more cheaply than speeding up the fix itself.

How to calculate MTTD

The formula is simple: add up the detection time of every incident in a period and divide by the number of incidents.

MTTD = sum(detected_at - started_at) / number_of_incidents

An illustrative example: in one month a team has four incidents with detection times of 3, 7, 12 and 38 minutes. The MTTD is (3 + 7 + 12 + 38) / 4 = 15 minutes. Notice that the single slow detection dominates the average. That is why many teams also report the median or a high percentile and review the outliers individually.

The hard part is not the arithmetic but the timestamps. detected_at is easy to record from the alert or ticket. started_at is usually reconstructed after the fact during the postmortem by looking at telemetry: when did the error rate, latency or saturation first deviate from normal?

Why MTTD matters

• User impact accumulates silently. Every minute before detection is a minute of failed checkouts or slow pages that nobody is working on.
• Customers should not be your monitoring. If incidents are regularly reported by users first, detection coverage has gaps.
• It exposes monitoring quality. A high MTTD points to missing signals, thresholds that are too loose or alerts that are routed to nobody.
• It protects the error budget. Slow detection lets an outage consume reliability targets before anyone reacts.

MTTD in the incident lifecycle

MTTD is one of several time-based incident metrics that together describe how a team responds. Keeping them separate shows where time is actually lost:

Metric	Measures the time from	Mainly influenced by
MTTD	Incident start to detection	Signal coverage, alert rules, synthetic checks
MTTA (Mean Time to Acknowledge)	Alert to a human taking ownership	Routing, on-call setup, notification channels
MTTR (Mean Time to Resolve or Restore)	Incident start or detection to recovery	Diagnosis tooling, runbooks, rollback ability
MTBF (Mean Time Between Failures)	One failure to the next	Design quality, testing, change management

A team with a short MTTR but a long MTTD fixes problems quickly once it knows about them, but finds out too late. The improvement lever is then monitoring, not debugging skills. Segment MTTD by severity as well: detection of a complete outage and detection of a slow, partial degradation are very different problems and deserve separate targets.

How to reduce MTTD

• Alert on symptoms users feel. Error rate, latency and availability per service, as described by the golden signals, catch more incidents than low-level host metrics.
• Use SLO burn-rate alerts. They fire quickly for severe problems and still catch slow degradations, without alerting on every blip.
• Add outside-in checks. Synthetic monitoring detects broken login or checkout flows even when traffic is low, for example at night.
• Use baselines instead of static thresholds for metrics with daily or weekly patterns, so deviations are flagged as soon as they leave the normal range.
• Fight noise. Paradoxically, too many alerts increase MTTD, because real alerts drown in noise. Reducing alert fatigue is a detection improvement.
• Mark deployments. Linking errors to a release makes regressions visible within minutes.

Common mistakes

• Measuring from alert to acknowledgement and calling it MTTD. That is time to acknowledge, a different and later phase.
• Excluding incidents that were reported by customers, which hides exactly the detection gaps you want to find.
• Comparing MTTD across teams with different incident definitions or severity scales.
• Optimizing MTTD by lowering every threshold, which trades detection speed for a flood of false positives.
• Relying on averages alone when only a handful of incidents happen per quarter.

How Obseria helps

Obseria evaluates SLOs with multi-window burn-rate alerts and applies baseline-based anomaly detection to metrics, traces and logs, so deviations surface early. Synthetic checks cover critical user journeys from outside. Detection and acknowledgement timestamps are recorded in incident management, which makes MTTD measurable per service and severity instead of estimated.