Time to Detect
also called MTTD
The interval between a problem beginning and someone knowing about it, which is often the largest and most reducible component of total incident duration.
Incident duration decomposes into detect, diagnose, and repair, and organisations focus almost entirely on the last two while the first is frequently the longest.
The signature of a detection problem is an incident that begins with a customer report or a colleague's message. When the outside world tells you your system is broken, detection has failed regardless of how quickly the team then responds — and the reputational cost of that pattern is disproportionate.
The causes are consistent: alerting on causes rather than symptoms, so a novel failure trips nothing; thresholds set so conservatively that a partial failure stays under them; monitoring that covers infrastructure but not user journeys; and no synthetic checks on critical paths that have low traffic overnight.
The remedies are direct. Symptom-based alerting on error rate, latency and journey success. Synthetic transactions exercising critical paths continuously, which detects failures during quiet periods that real traffic would not reveal for hours. Burn-rate alerting so a slow degradation is caught while it is still slow. And measuring detection time explicitly in every postmortem, which is what makes it improvable rather than invisible.
The related figure worth tracking alongside it is the proportion of incidents detected internally versus externally. It is a single number, it is easy to compute, and it says more about observability maturity than any tooling inventory.