# MTTR vs MTTD: What's the Difference?

> MTTD (mean time to detect) measures how quickly you notice an incident; MTTR (mean time to resolve) measures how quickly you fix it. Together they define how long users feel your failures.

Source: https://openobserve.ai/glossary/mttr-vs-mttd/
Published: 2026-07-08
Term: MTTR vs MTTD
Category: SRE & Incident Response
Related terms: slo-sla-sli, what-is-error-budget, what-is-dora-metrics, four-golden-signals

---

**MTTD (Mean Time to Detect)** and **MTTR (Mean Time to Resolve)** are the two clock measurements of incident response. MTTD is the average time between a problem starting and your team knowing about it; MTTR is the average time from start (or detection, depending on convention) to the problem being fully fixed. Users experience the sum: every minute of either is a minute of degraded service.

## The incident timeline

A typical incident breaks into phases, each with its own "mean time" metric:

1. **Failure begins** → **MTTD**: time until an alert fires or a human notices
2. **Detection** → **MTTA** (mean time to acknowledge): time until someone starts working
3. **Acknowledgment** → diagnosis → fix → **MTTR**: time until service is restored

Long MTTD is an *alerting* problem: missing coverage, cause-based alerts that don't fire on novel failures, or [alert fatigue](/blog/alert-fatigue/) burying real signals. Long MTTR after detection is usually a *diagnosis* problem: engineers can see that something is wrong but not where or why - precisely what [observability](/glossary/what-is-observability/) exists to fix.

## Why the distinction matters

Teams that only track MTTR often optimize the wrong phase. If a 90-minute outage was 60 minutes undetected, better dashboards for responders won't move the needle - better alerting will. Splitting the clock tells you where the time actually goes. The [MTTR guide](/blog/mean-time-to-resolution-mttr-guide/) covers measurement pitfalls in detail (including the ambiguity of the "R": resolve, respond, repair, or recover).

## Reducing both

- **MTTD** - symptom-based alerts on the [golden signals](/glossary/four-golden-signals/), SLO burn-rate alerting, anomaly detection for the failures you didn't predict
- **MTTR** - correlated logs/metrics/traces so diagnosis is a pivot rather than a tab-switch, runbooks attached to alerts, [alert correlation](/blog/reduce-mttd-mttr-openobserve-alert-correlation/) so responders see one incident instead of forty notifications

## Tracking them in OpenObserve

OpenObserve's [alerting](/alerts/) and [incident management](/incidents/) correlate related alerts into incidents, timestamp the detection-to-resolution timeline, and - with AI-assisted [root cause analysis](/ai-sre/) - shorten the diagnosis phase that dominates most MTTRs.