Teams obsess over how fast they fix. The clock that usually dominates an incident is the one nobody watches: how long the problem ran before anyone knew it existed.
MTTD — mean time to detect — is the average gap between a problem beginning in production and the team knowing about it. It is reduced by closing detection blind spots (frontend errors, per-endpoint failures, silent jobs), shortening check intervals with confirmation, alerting on deviation from baselines rather than hard failure, correlating signals so alerts stay credible, and routing findings to a named owner. For teams that rely on user reports or log archaeology, MTTD is measured in hours to days — usually the largest single component of incident duration, and the cheapest to cut.
Decompose incident duration: time to detect, then time to acknowledge, diagnose, fix, verify. Postmortems lavish attention on the later phases — the diagnosis that took an hour, the fix that needed a rollback. But for any team without systematic detection, the first phase quietly dwarfs them: a partial failure that runs from Friday evening to Monday's first complaint has an MTTD of sixty hours attached to a two-hour fix.
And detection lag is pure loss. During diagnosis and repair, at least the damage is being worked on; during the not-knowing, failed conversions, lost data and eroding trust accumulate at full rate with zero countervailing effort. Cutting an hour of MTTD is worth exactly as much as cutting an hour of repair — and it is almost always cheaper, because detection improves by configuration while repair improves by engineering.
Four causes, in descending order of typical impact:
MTTD only improves if the start of the clock is honest: when the problem began, not when the alert fired. Reconstruct onset from telemetry — the first anomalous check, the error spike's leading edge — and log detection time per incident alongside how it was detected (check, warning, user report). Three practices keep the number meaningful:
Detection time is only as good as the team's willingness to read the alert — alert fatigue is the failure mode that undoes everything above.
| Definition | Mean gap between a problem beginning in production and the team knowing about it |
|---|---|
| Typical unmonitored MTTD | Hours to days — until a user report or accidental discovery |
| Largest driver | Blind spots: failure classes with no automatic detector at all |
| Bounding formula | Check interval × confirmation count — e.g. 5 min × 2 ≈ 10-minute worst case for hard failures |
| Going below zero | Baseline-deviation alerting detects the deterioration phase before failure |
| Detection endpoint | A responsible human knows — routing and credibility lag count as MTTD |
| Best single KPI | Share of incidents first detected by your own systems vs by users |
MTTD — mean time to detect — is the average time between a problem beginning in production and the team becoming aware of it. It sits before acknowledgement, diagnosis and repair in the incident timeline, and for teams without systematic monitoring it is typically the longest phase, measured in hours or days.
MTTR (mean time to resolve/repair) usually measures from detection or acknowledgement to resolution — the visible, worked part of an incident. MTTD measures the invisible part before it: how long the problem ran with nobody knowing. Damage accrues through both, but MTTD's damage accumulates with zero countervailing effort, which is why cutting it is the cheapest reliability win available.
For hard failures, minutes: outside-in checks at a five-minute interval with two-failure confirmation bound detection at roughly ten minutes, and one-minute checks at about two. For degradation-class problems, good means detecting during the deterioration phase — before outright failure — which requires baseline-deviation alerting rather than hard thresholds.
Close blind spots first: add browser error collection, individual checks on revenue-path endpoints, and liveness signals for background jobs — each converts a detect-by-accident failure class into detect-in-minutes. Then make every signal push-based, alert on deviation from baselines, correlate signals so alerts stay credible, and route findings to named owners. Blind-spot closure alone typically cuts average MTTD by more than any tooling upgrade.
Directly. A noisy channel gets muted, and a muted channel gives every subsequent incident effectively infinite detection time regardless of how fast the underlying detector fired. Correlation (one cause, one alert), confirmation before alerting, and severity-based routing are MTTD investments as much as courtesy.
Per incident, reconstruct the true onset from telemetry — the first anomalous check or the error spike's leading edge — and measure to the moment a responsible human knew. Track the average, but also the detection-source ratio: what share of incidents your own systems caught first versus users. That ratio is the clearest single indicator of monitoring maturity.
Merik attacks every term in the MTTD equation. Blind spots: browser errors via merik.js, per-endpoint checks with assertions, SSL expiry, vendor status — the classes teams usually discover by accident, detected automatically. Frequency and confirmation: checks every few minutes, two failures before an incident, so hard-failure detection is bounded in minutes without blip noise. Deviation: 14-day baselines per monitor turn deterioration into early warnings — detection before the failure phase begins.
Credibility and routing are enforced by design: correlated signals become one warning or one incident, alerts send once, severity gates what may interrupt outside working hours, and every asset has an owner who gets the assignment automatically. The scoreboard is built in too — incidents record how they were detected, and warnings link to the incidents they predicted, so the "caught by us vs caught by users" ratio is a number you watch improve, not a feeling.
APIs degrade before they die — latency drift, timeouts, error trickles. Monitoring that listens.
The monitoring that pays for itself this week, and the monitoring that can wait a year.
Five causes, six rules, and the two numbers that say whether your alerts are worth reading.