Mean Time To Detect (MTTD) is the average amount of time that passes between the moment a problem actually starts in a system and the moment someone or something notices it. It applies to production outages, performance regressions, software bugs, and security breaches alike. The metric is calculated across a group of incidents, not a single one, which is why it carries the word "mean" in its name. A team with a low MTTD catches trouble quickly; a team with a high MTTD is often operating with a blind spot it doesn't know exists yet.
The reason mean time to detect exists is that fixing a problem and finding a problem are two entirely different skills, and teams used to conflate them. For decades, incident reporting focused almost entirely on resolution speed: how fast did we patch it, how fast did we restore service. That framing quietly ignored the period before anyone knew anything was wrong, which is often the most expensive part of an incident. A database that silently corrupts records for six hours before anyone notices does far more damage than one that breaks loudly and gets fixed in twenty minutes. MTTD exists to put a number on that invisible window, so organizations can manage it instead of treating it as an unavoidable cost of doing business.
Calculating MTTD is straightforward in principle: take the detection time minus the start time for every incident in a period, add those durations together, and divide by the number of incidents. The hard part is agreeing on what "start" and "detected" actually mean, because both are judgment calls. Start time is usually reconstructed after the fact from logs, deploy timestamps, or customer complaints, and detection time is the moment a monitoring system fires an alert, a human notices an anomaly, or a support ticket lands that gets correctly triaged as a real incident. MTTD sits at the front of a chain of related metrics. Mean Time To Acknowledge (MTTA) picks up right where MTTD ends, measuring how long it takes a responder to actually engage once alerted. Mean Time To Resolve (MTTR) covers the work of fixing the problem after it's acknowledged. Mean Time Between Failures (MTBF) is a different animal entirely, measuring how often failures happen at all rather than how fast any single one is caught. Together these four metrics describe the full life cycle of an incident, from onset to closure.
By 2026, MTTD carries more weight than it used to, mostly because systems have gotten harder to watch. Distributed architectures, microservices, and third-party dependencies mean a single user-facing failure can originate from dozens of possible places, and no single dashboard shows the whole picture anymore. Observability tooling has matured to fill that gap with distributed tracing, structured logging, and anomaly detection, but the same tooling has created a new problem: alert volume. Teams now fight alert fatigue as much as they fight actual incidents, and a flood of low-value notifications can bury the one signal that mattered, quietly dragging MTTD upward even as monitoring coverage expands. Security teams face a parallel version of this same pressure, since attackers who dwell undetected inside a network for a long stretch can do dramatically more damage than one who trips an alarm on entry.
This page covers how MTTD is actually calculated in practice, how it relates to MTTA, MTTR, and MTBF within a single incident timeline, what pushes it up or brings it down, where it stops being a useful number to chase, and how a team gets started measuring and improving it. The underlying idea that survives all of that detail is simple: you cannot manage what you cannot see, and MTTD is the number that tells you how long you were unable to see the thing that was already hurting you.
The formula for MTTD looks deceptively simple: sum the detection time for every incident in a given period, then divide by the number of incidents. If a team handled ten incidents last month and the combined detection time across all of them was 300 minutes, MTTD for that month is 30 minutes. The arithmetic is not where the difficulty lives. The difficulty lives in defining the two timestamps that feed the formula, and different teams make different choices that are not always comparable to each other.
The first timestamp, when the problem actually started, is almost never recorded directly. Nobody sets off an alarm the instant a bad deploy ships or a disk starts filling up; that moment is reconstructed after the fact by looking at logs, metrics, deploy history, or the earliest customer report that correlates with the failure. This reconstruction work is genuinely difficult for slow-building problems like memory leaks or gradual data corruption, where there is no clean instant you can point to and say "this is when it began." Teams often settle on a working definition, such as the first point where a monitored metric crossed an abnormal threshold, even if the underlying cause predates that crossing by hours.
The second timestamp, when the problem was detected, has its own ambiguity. Detection can mean an automated monitor firing an alert, a human noticing something odd on a dashboard, a customer support ticket that gets correctly identified as a systemic issue rather than a one-off complaint, or a security tool flagging anomalous behavior. Some organizations only count automated detection as "real" detection, on the theory that relying on customers to report outages is a failure of monitoring in itself. Others count any of these paths, since a support ticket that surfaces a real problem is still detection, just a more expensive and slower kind. Whichever definition a team picks, consistency matters more than the specific choice, because MTTD is only useful when it's tracked the same way over time.
Most teams calculate MTTD from data already sitting in their incident management platform, correlating deploy logs, monitoring alerts, and incident timestamps automatically rather than doing this by hand. It's also common to segment MTTD by severity or by system, since a P1 outage and a minor UI glitch should not be averaged together as if they carry equal weight. A team that reports a single blended MTTD across every kind of incident is usually hiding more than it's revealing, because a handful of fast-caught trivial bugs can make average detection time look far better than it is for the incidents that actually matter.
These four metrics describe four different segments of the same incident, and it helps to walk through a single failure chronologically to see where each one starts and stops. Picture a payment service that starts silently dropping a fraction of transactions at 2:00 AM because of a bad configuration change. The clock for MTTD starts ticking right then, at 2:00 AM, even though nobody knows it yet.
At 4:30 AM, a monitoring system finally notices the error rate anomaly and fires an alert. That two-and-a-half-hour gap between 2:00 AM and 4:30 AM is the detection window, the piece MTTD measures. The alert then sits for eighteen minutes before an on-call engineer acknowledges it at 4:48 AM; that eighteen-minute stretch is MTTA, the acknowledgment gap. From there, the engineer investigates, identifies the bad configuration, and rolls it back by 5:40 AM. The 52 minutes between acknowledgment and resolution is MTTR. Add it all up and the full incident, start to finish, ran two hours and forty minutes, but each of those three metrics tells a different story about where the time actually went, and in this example, detection was by far the largest chunk of the total.
MTBF sits outside this single-incident timeline entirely. Rather than measuring how any one incident unfolded, it measures how often incidents like this one happen in the first place, calculated as the average time between failures across a longer stretch. A system can have an excellent MTTD, catching every failure within minutes, while still having a poor MTBF because it fails constantly. Conversely, a system might fail rarely (good MTBF) but take a very long time to notice each failure when it does happen (poor MTTD). The four metrics are complementary, not redundant, and a team that only tracks one or two of them is missing real information about where their reliability problems actually live.
This is also why comparing MTTD in isolation across teams or companies is misleading without context. A team with a high MTTD but a low incident count overall might be in better shape than a team with a low MTTD but frequent failures, because the total cost of unreliability is a function of all four numbers together, not any single one viewed alone. Good incident review practice looks at the whole timeline. The question that actually matters isn't just how fast the team detected the problem. It's where in the chain the most time got lost, and whether that's a pattern that keeps showing up across incidents.
Monitoring coverage is the most obvious lever, and also the most misunderstood one. It's tempting to assume that more monitoring automatically means faster detection, but coverage only helps if it's watching the right things. A team can have dashboards for CPU, memory, and disk while missing the one business metric, like checkout completion rate or login success rate, that would have caught the actual incident hours earlier. The best-performing teams build monitoring around user-facing outcomes and business-critical paths first, then add infrastructure-level metrics underneath, rather than the other way around. Detection is fastest when the alert is tied directly to the thing customers actually experience, not a proxy metric several layers removed from it.
Alert fatigue works in the opposite direction, quietly sabotaging detection even in well-instrumented environments. When responders receive a constant stream of low-value or noisy alerts, they start treating all alerts with less urgency, and a real signal can sit unacknowledged in a sea of false positives. This is one of the more counterintuitive dynamics in reliability work: adding more alerts, without also tuning thresholds and removing noisy ones, often makes MTTD worse rather than better. Signal-to-noise ratio matters more than raw alert volume. A team that trims its alerting down to a smaller number of high-confidence signals will typically detect real incidents faster than a team drowning in notifications, even if the second team technically has "more monitoring."
Observability maturity plays a similar role, particularly in distributed systems where a single failure can originate several services away from where the symptom shows up. Structured logging, distributed tracing, and correlated metrics let engineers connect a spike in checkout errors to the specific downstream service that caused it, rather than starting from scratch every time. Without that connective tissue, teams often detect that something is wrong well before they can pinpoint what and where, and the ambiguity itself delays a clean detection timestamp. Mature observability doesn't just tell you that something broke; it tells you fast enough, and specifically enough, for detection to actually mean something actionable.
Team structure and on-call design matter too, in ways that are easy to overlook. An alert that fires correctly but routes to the wrong team, or that requires escalation through several layers before reaching someone who can act, adds real time to the detection-to-acknowledgment handoff even when the underlying monitoring worked perfectly. Clear ownership boundaries, well-tuned escalation policies, and alerts that route directly to the team that owns the affected system all shrink the practical gap between "something is wrong" and "the right person knows." None of this requires exotic tooling. It requires deciding, in advance, who is supposed to see which signals and making sure the routing actually reflects that decision.
MTTD is a useful number, but it's easy to over-optimize for it in ways that create their own problems. The most common failure mode is chasing a lower MTTD by adding alert thresholds that are so sensitive they generate constant false positives. This can make the metric look better on a dashboard while actually making the team's day-to-day experience worse, because responders spend their time chasing noise instead of trusting the signal. A falling MTTD number that's driven by hypersensitive alerting rather than genuinely better detection is not real progress; it's a metric being gamed, even if unintentionally.
MTTD also says nothing about severity, and treating all detection times as equally important is a mistake. Detecting a minor cosmetic bug in two minutes and detecting a full payment outage in two minutes are not equivalent achievements, even though they produce the same number. A team fixated on overall average MTTD might spend disproportionate energy on fast detection for low-stakes issues while a slower-to-detect but far more damaging class of incident goes unaddressed. Segmenting the metric by severity and by system, as mentioned earlier, is not optional polish; it's what keeps the number honest.
There's also a category of problem that MTTD structurally cannot capture well: issues with no clear start time at all. Gradual data drift, slow performance decay, or a security vulnerability that existed in code for months before being exploited don't have a clean "this is when it began" moment, which makes the detection window somewhat arbitrary no matter how carefully it's reconstructed. For these cases, MTTD is still worth calculating, but it should be treated as a rough estimate rather than a precise measurement, and teams should be cautious about setting hard targets around numbers that carry that much inherent fuzziness.
Finally, MTTD is a lagging indicator of monitoring quality, not a direct lever you can pull. You cannot decide to have a lower MTTD the way you can decide to ship a feature faster; you can only improve the things that produce a lower MTTD, like monitoring coverage, alert design, and observability depth. Teams that treat the number itself as the goal, rather than as a diagnostic output of underlying practices, tend to make surface-level changes that move the number without changing the actual detection capability. The metric is valuable as a way to notice whether those underlying practices are improving or decaying over time, not as a target to hit through shortcuts.
The starting point is almost always less glamorous than people expect: get incident data into one place with reliable timestamps. Many teams discover, the first time they try to calculate MTTD seriously, that their incident records don't actually capture a clean start time or detection time at all, just a vague description and a resolution note. Before improving the metric, a team usually needs to fix its incident documentation habits, requiring responders to log when an alert fired, when it was acknowledged, and, as best as can be reconstructed, when the underlying problem actually began.
Once that data exists, the next step is establishing a baseline rather than jumping straight to improvement efforts. Calculate MTTD across the last quarter or two of incidents, segmented by severity, and resist the urge to act on a single bad month, since incident-heavy periods can be skewed by one or two unusual events. A baseline built from a reasonable sample size gives a team something honest to compare against later, rather than chasing noise in month-to-month swings.
From there, improvement work usually falls into a short list of concrete moves rather than anything exotic. Auditing existing alerts for signal-to-noise ratio and retiring or retuning the noisy ones tends to produce quick wins, since it directly addresses alert fatigue. Adding monitoring for business-critical user journeys, not just infrastructure health, closes the gap between "the servers look fine" and "customers can actually complete a purchase." Reviewing escalation and routing rules ensures that when an alert does fire correctly, it reaches someone who can act on it without unnecessary hops. None of these changes require a large tooling investment; most are a matter of discipline and prioritization applied to systems teams already have.
Finally, MTTD should be reviewed as part of regular incident retrospectives, not just as a quarterly dashboard number. When a team walks through a specific incident and asks concretely why detection took as long as it did, whether it was a coverage gap, a noisy alert queue, a routing failure, or a genuinely hard-to-spot slow-building issue, the answers point directly at what to fix next. Treating MTTD as a live input to blameless postmortems, rather than a static score, is what turns the metric from a reporting exercise into an actual driver of better reliability practice.
Mean Time To Detect (MTTD) is the average time between when a problem actually begins in a system and when someone or some monitoring tool notices it. It's calculated by averaging detection times across a group of incidents, and it's used across incident management, site reliability engineering, and security to measure how long an organization was effectively blind to something already causing harm.
MTTD covers the period before a problem is known about, from onset to detection. MTTR covers the period after a problem is acknowledged, measuring how long it takes to actually fix it. A team can have an excellent MTTR, resolving issues quickly once someone is working on them, while still having a poor MTTD if problems sit undetected for a long time before anyone starts that resolution work.
There's no universal number, because it depends heavily on the type of system, the severity of the incidents being measured, and the industry. A payment processing system handling financial transactions needs far faster detection than an internal reporting tool with no direct customer impact. Rather than chasing an external benchmark, most teams are better served by tracking their own MTTD over time, segmented by severity, and working to bring it down relative to their own history.
In a security context, MTTD often gets discussed as breach detection time or dwell time, the length of time an intruder or malicious process operates inside a system before being noticed. Longer dwell time generally gives an attacker more opportunity to move through a network, access sensitive data, or cause damage, which is why security teams treat detection speed as one of the most consequential metrics in the entire incident response process.
MTTD itself isn't really something that can be "too low" in a harmful sense, but the way a team achieves a low number matters. If detection speed improves because of genuinely better monitoring and observability, that's a real gain. If it improves because alert thresholds were set so sensitively that they generate constant false alarms, the number looks better while the team's actual workload and trust in alerts gets worse, which defeats the purpose.
Yes. It's commonly applied to software defects as well, comparing how long a bug existed before it was caught by automated testing or monitoring versus how long it existed before a user reported it. Bugs caught internally through testing generally represent a much shorter, cheaper detection window than bugs that reach production and are only discovered through user complaints, which is part of why investment in automated testing directly affects this metric.
MTTD is typically calculated from data already captured in monitoring platforms, log aggregation tools, and incident management systems, which record when alerts fire and when problems are acknowledged. The harder part isn't the tooling itself but reconstructing an accurate start time for each incident, which often requires correlating deploy logs, error rate changes, and the earliest related customer reports rather than relying on a single automated timestamp.
Alert fatigue happens when responders receive so many low-value or false-positive alerts that they start treating all alerts with less urgency, including the real ones. This directly increases MTTD because a genuine signal can sit unacknowledged in a queue of noise for longer than it should. Reducing alert volume and improving signal-to-noise ratio is one of the most reliable ways to bring detection time down, often more effective than simply adding new monitoring.
Most teams review MTTD as part of regular incident retrospectives, looking at individual incidents to understand specifically why detection took as long as it did, and also on a periodic basis, such as quarterly, to spot longer-term trends across severity levels and systems. Reviewing it too infrequently risks missing a gradual decline in detection quality, while reviewing only in aggregate, without looking at specific incidents, risks missing the concrete fixes that would actually move the number.
