What is MTTD?
MTTD (mean time to detect) is the average time between the start of an incident and the moment it is detected, by monitoring or by a person. It is calculated as the sum of detection delays divided by the number of incidents. A lower MTTD shortens every outage, because nothing can be fixed before it is noticed.
Why MTTD matters
Detection time is pure downtime: users are affected and nobody is working on the problem yet. For short incidents it is often the largest part of the total.
MTTD depends mostly on choices you control: the check interval, confirmation retries, alert thresholds, and whether you watch what users actually do. A customer reporting an outage before your monitoring did is the clearest sign MTTD is too long.
How to measure MTTD
MTTD = Σ (detected − started) ÷ number of incidents worst-case detection for an outside check ≈ check interval + confirmation delay
Worked example
Four incidents last quarter were detected 3, 11, 1 and 5 minutes after they started. The 11-minute one was a cron job that failed silently until someone looked.
- Sum of detection times = 3 + 11 + 1 + 5 = 20 minutes.
- MTTD = 20 ÷ 4 = 5 minutes.
- With a 1-minute check interval and a 12-second confirmation, an outright outage is detected within about 60 + 12 = 72 seconds.
Result: The average is dominated by the silent cron failure. A heartbeat on that job would have cut its detection to the grace period and brought MTTD down far more than faster HTTP checks.
Common mistakes
- Measuring from the alert. The start is when users were first affected, which you often learn from logs afterwards. Measured from the alert, MTTD is zero by definition.
- Long intervals on critical paths. A 15-minute interval means up to 15 minutes of undetected downtime.
- Only checking the homepage. Login, checkout and the API can fail while the homepage works.
- Ignoring silent failures. Jobs that do not run never raise an error. They need heartbeats.
How Vigil handles MTTD
- Uptime and API checks run at the interval you set per monitor (the fastest allowed depends on the plan), and each failure is confirmed by a second check about 12 seconds later.
- Heartbeats catch jobs that never run, browser checks catch broken user journeys, and adaptive latency alerts catch slowdowns that are not errors yet.
- Each incident records when it was detected, so you can compare detection with the start time you find in logs, and Time Detective shows what happened just before.
MTTD (mean time to detect): frequently asked questions
What is a good MTTD?
For an outright outage of a monitored endpoint, minutes or less, limited by the check interval. Subtle problems such as slow pages or wrong data usually take longer; the aim is to shorten it over time.
How do I reduce MTTD?
Check more often, monitor what users do (APIs, logins, checkouts) and not only the homepage, add heartbeats for jobs, and alert on latency and error-rate changes as well as hard failures.
Is MTTD part of MTTR?
When MTTR is measured from the start of the incident, yes: detection time is included. When it is measured from the alert, it is not. Say which you use.