Incident reviews love MTTR. Dashboards look serious with a trending line. Meanwhile the outage may have been live for twenty minutes before anyone's phone buzzed. That gap has a name.
The two clocks
MTTD (mean time to detect): from when customers (or the system) actually broke to when your team knew. Driven by check interval, confirmation logic, and whether anyone was watching the right channel.
MTTR (mean time to resolve): from detection (or from incident open; pick one definition and stick to it) to mitigation or full fix. Driven by runbooks, access, escalation, and how hard the bug is.
Customer pain is roughly MTTD + time-to-mitigate. Bragging only about MTTR hides a slow smoke alarm.
Which to fix first
For a young SaaS: MTTD.
- Move critical checks to about one minute.
- Confirm failures so you do not drown in noise (false downtime).
- Put pages where someone will answer (page vs notify).
You can cut MTTD in a week with tooling and discipline. Cutting MTTR often needs better architecture, better runbooks, and fewer 2am first-times. That is slower work.
Once detection is trustworthy, attack MTTR with runbooks, clearer ownership, and escalation that does not stall.
How to measure without lying
- Start time: first confirmed failed check (or first customer report if you were blind; then your MTTD was infinite and you should say so).
- Detected: first human ack, or automated incident open if that is when the team is notified.
- Resolved: customer impact gone, not "PR merged."
Write the definitions on the wiki. Otherwise every postmortem invents new math.
A useful monthly review
Look at the last five incidents. For each: MTTD, time-to-ack, time-to-mitigate. If MTTD dominates, buy detection. If ack is slow, fix channels and escalation. If mitigate is slow, fix the system and the docs. One number for "MTTR" that mixes all three will send you to the wrong fire.
