MTTR vs MTTD: What's the Difference?

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:

Failure begins → MTTD: time until an alert fires or a human notices
Detection → MTTA (mean time to acknowledge): time until someone starts working
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 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 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 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, 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 so responders see one incident instead of forty notifications

Tracking them in OpenObserve

OpenObserve’s alerting and incident management correlate related alerts into incidents, timestamp the detection-to-resolution timeline, and — with AI-assisted root cause analysis — shorten the diagnosis phase that dominates most MTTRs.

Frequently asked questions

What does MTTR stand for?

MTTR most commonly means mean time to resolve (or repair) - the average time from incident start to full resolution. Beware that teams also use it for mean time to respond or recover, so agree on a definition before comparing numbers across teams or vendors.

What is a good MTTR?

It depends on service criticality and industry, but elite DevOps performers in the DORA research restore service in under one hour, while median teams take a day or more. The trend matters more than the absolute number - a falling MTTR means detection, diagnosis, and remediation are all improving.

How do you reduce MTTD?

Alert on user-facing symptoms (latency, error rate) rather than only causes, set SLO-based alerts on burn rate, ensure coverage of every critical path, and reduce alert noise so real signals aren't buried. Most long detection times are alerting-coverage gaps, not tooling gaps.