What is MTTD?

#How MTTD is measured

The clock starts when the failure actually began and stops when it was detected. The first endpoint is the difficult one, because determining when a problem truly started usually requires retrospective analysis of metrics after the incident is over.

That reconstruction is worth doing. Detection time is invisible during the incident itself, and the only way to know whether monitoring caught a failure in ninety seconds or forty minutes is to go back and find the point where the metrics first diverged from normal.

#Why MTTD matters

Detection time is pure loss. The failure is affecting users and nobody is working on it.

• Direct impact: every minute of detection delay is a minute of unmitigated user harm.
• Coverage signal: high MTTD identifies exactly which failure modes are unmonitored.
• Escalating cost: the longer a failure runs, the more state it corrupts and the harder recovery becomes.
• Discovery source: tracking who detected the problem reveals whether customers are your monitoring.

#Limits and blind spots

MTTD can only be calculated for failures that were eventually detected. Problems that were never noticed contribute nothing to the metric, which means the number systematically flatters monitoring coverage.

Averages also hide the important cases. Well monitored failure modes are caught in seconds and pull the mean down, while the rare unmonitored failure that ran for six hours is the one that caused real damage. The distribution and the worst case matter more than the average here than for most metrics.

#MTTD vs MTTR

MTTD covers detection. MTTR covers everything from detection through restoration, including acknowledgment, diagnosis, and the fix itself.

They point at different investments. Reducing MTTD means better instrumentation, symptom based alerting, and anomaly detection on signals nobody thought to threshold. Reducing MTTR means better diagnostic tooling, runbooks, and rehearsed remediation. A team with excellent MTTR and poor MTTD fixes things quickly once it knows, which is little comfort to users during the hour before it knew.

#Key takeaways

• MTTD runs from when the failure began to when it was detected, and the start point requires retrospective analysis.
• Terminology and endpoint definitions vary across organizations and tools; publish the exact local definition alongside the metric.
• Detection time is unmitigated user impact with nobody working on the problem.
• The metric only counts failures that were eventually found, so it systematically flatters coverage.
• Tracking who detected each incident reveals whether customers are functioning as your monitoring.

#Frequently asked

How do you find when a failure actually started?

Work backward through metrics after the incident to locate the first divergence from normal. This is a standard part of a thorough postmortem.

What is the strongest lever on MTTD?

Alerting on user visible symptoms such as error rate and latency rather than only on internal causes. Symptom alerts catch failure modes nobody anticipated.

What does it mean when customers report issues first?

That the failure mode is unmonitored. Every customer reported incident should produce a monitoring change so the same class is caught internally next time.