MTTR vs MTTD vs MTTA vs MTTF: The Incident Metrics That Actually Matter

Most articles on these metrics teach them with light bulbs. A bulb lasts 20 hours, another lasts 18, average them, done. That math is correct and it is useless, because production systems do not fail like light bulbs. They fail at 3am, on a healthy-looking node, with an alert that blames the wrong thing.

This guide covers the four metrics with formulas and examples, the same as everyone else. Then it does the part nobody else does. It takes a real production incident we investigated and measures it phase by phase, so you can see where the time actually goes. Because the point of these metrics is not to fill a dashboard. It is to tell you what to fix.

What Are MTTR, MTTD, MTTA, and MTTF?

Four metrics, four different questions. One more, MTBF, shows up constantly alongside them, so it is included here too.

The trap in all five is the word mean. These are averages. One brutal outage can wreck your MTTR for the quarter even if the team executed well every other time. So the number on any single day means little. The trend over a 30-day rolling window is the thing to watch.

How Do These Metrics Map to the Incident Lifecycle?

A single failure moves through phases, and each metric measures a different stretch of that timeline.

A service breaks. Some time passes before monitoring notices, that gap is MTTD. An alert fires, and some more time passes before a human acknowledges it, that gap is MTTA. Then the work happens: diagnose the cause, apply a fix, verify recovery. The whole span, from the moment of failure to fully restored service, is MTTR. MTBF and MTTF do not live on this timeline at all. They measure the gaps between failures, not the handling of one.

Here is the sequence, laid out:

Notice the three unlabeled rows in the middle. Diagnose, fix, verify. They have no famous acronym, and they are usually the largest part of MTTR. Hold that thought, because it is where most of the real time hides and where most teams look last.

What Is MTTD (Mean Time to Detect)?

MTTD is the average time between when a failure starts and when your monitoring detects it. It measures the window of invisible downtime, the period where something is broken, customers feel it, and your team has no idea yet.

The formula:

MTTD = Sum of (detection time - failure start time) per incident / number of incidents

If four incidents had detection lags of 3, 7, 2, and 8 minutes, MTTD is 5 minutes. That is five minutes of average customer impact that never shows up in your MTTA or MTTR unless you track detection on its own.

What drives MTTD up is almost always monitoring coverage. Health checks that run every five minutes set a five-minute floor on detection. Tightening intervals and alerting on real signals, the kind Prometheus exposes directly, pulls that floor down. Alert thresholds tuned only for total failure miss the slow degradations. And the worst signal of all: users reporting the problem before your monitoring does. If that happens, your real MTTD is being measured in customer complaints.

What Is MTTA (Mean Time to Acknowledge)?

MTTA is the average time between an alert firing and a human confirming they are on it. It is the narrowest of the four, covering one handoff: machine to person.

MTTA = Total time from alert to acknowledgment / number of alerts acknowledged

Ten alerts, 90 total minutes to acknowledge, MTTA is 9 minutes.

MTTA is usually the easiest win of the whole set, because its causes are structural, not technical. Alert fatigue trains engineers to ignore a noisy feed, so a real alert gets the same shrug as the noise. Broken on-call routing sends the page to the wrong person. Missing escalation means an unacknowledged alert just sits there. Fix routing and escalation and MTTA drops without touching a single line of infrastructure.

What Is MTTR, and Why Does the R Mean Four Different Things?

MTTR is the one everyone quotes and the one everyone defines differently, because the R is overloaded. It can mean Recover, Repair, Resolve, or Respond, and they are not interchangeable.

Before any team tracks MTTR, it has to agree on which R it means, or the number is noise.

The most common and most useful version is Recover, because it maps directly to customer pain:

MTTR = Total downtime / number of incidents

Three incidents, 120 minutes of total downtime, MTTR is 40 minutes.

Every minute of MTTR is a minute of degraded or down service. It is the number your SLA rests on and the first thing leadership asks about after a bad night. And because MTTR contains MTTD, MTTA, and the diagnose-fix-verify block, it is the metric most affected by improving any of the others.

What Is MTTF, and How Is It Different from MTBF?

This is where your title asks a real question, so here is a real answer instead of a footnote.

MTTF (Mean Time to Failure) is the average lifespan of a non-repairable component, something you throw away and replace when it dies. A hard drive, a sensor, a light bulb. It comes straight out of reliability engineering, where physical parts have measurable lifespans. MTBF (Mean Time Between Failures) is for repairable systems, things you bring back online after a failure. A server, a service, an application.

MTTF = Total operational time / number of units tested
MTBF = Total uptime / number of failures

The distinction is not academic. Use the wrong one and the number lies. MTTF also breaks down for anything long-lived: to get a true MTTF for a component meant to last years, you would have to run it for years, so teams estimate from short windows and the math gets shaky fast.

Here is the honest part most pages skip. If you run software and infrastructure, you will almost never use MTTF. Your systems are repairable, so MTBF is the right term nearly every time. MTTF belongs to hardware reliability engineering and manufacturing, where physical parts get replaced rather than restored. It earns a place in this comparison because people search for it, but in day-to-day SRE work it is the metric you will reach for least.

MTBF pairs with MTTR to give you availability, which is the number that actually lands in reliability reviews:

Availability = MTBF / (MTBF + MTTR)

Higher MTBF and lower MTTR mean higher uptime. Simple, and more meaningful than any single metric alone.

A Real Incident, Measured

Every other guide stops at light bulbs. Here is a real one.

A content-api service in production started returning 503s. The alert fired on the symptom, and the obvious guesses pointed at the application. The actual cause was somewhere else entirely: the deployment had scaled its replicas to zero, so the service had no healthy endpoints behind it. Nothing was crashing. There was simply nothing there to serve traffic. Root cause was confirmed in under five minutes, and the full investigation, including the hypotheses that were ruled out along the way, is written up in the 503 service outage RCA.

Now map the metrics onto it. Detection was effectively instant, because the monitoring was watching endpoint health, not just whether the homepage loaded, so MTTD was near zero. That is what good coverage buys you. The slow part, the part that decides the whole incident, was never the fix. Scaling replicas back up is trivial. The slow part is always diagnosis: proving it was empty endpoints and not the app, the database, the network, or the last deploy. That is the phase with no acronym, and it is the phase that dominates MTTR.

Compare it to a different failure from the same set. A pod got evicted from ephemeral storage exhaustion, where the node dropped to 510Mi of local disk against a 2.14GB threshold. The alert pattern there looked like memory. It was disk. Again, the fix was one line of configuration. Again, the entire cost of the incident sat in the diagnosis: ruling out the wrong resource before landing on the right one. More of these are on the Kubernetes examples page, and the pattern repeats. The symptom points one way. The cause is one layer down. And finding that layer is where your MTTR is really spent.

Where Does Investigation Time Hide Inside MTTR?

Look back at the lifecycle table. MTTD and MTTA get all the named attention, but on most real incidents they are the small slices. The big slice is diagnose, and it has no famous acronym, so it gets ignored in exactly the conversations where it matters most.

This has a direct consequence. If your detection and response are already tight and your MTTR is still high, the bottleneck is diagnosis, and no amount of faster paging will help. You need to shorten the time between an alert and a confirmed cause. That means better observability, runbooks for your most common failures, and correlation across signals so an engineer is not manually cross-checking logs, metrics, deploys, and Kubernetes events at 3am while the clock runs.

This is the phase an AI SRE is built to compress. Not the detection, not the paging, but the investigation itself: pulling the evidence together, forming and ruling out hypotheses, and arriving at the cause in minutes instead of an hour of manual correlation. For a deeper treatment of how that investigation works, see our guide on root cause analysis for production incidents. The reason it moves MTTR is simple arithmetic: cutting diagnosis from 40 minutes to 5 removes 35 minutes of customer-visible downtime, and it does it on the phase that was the largest to begin with.

What Do Good MTTR, MTTA, and MTTD Numbers Look Like?

Benchmarks are a starting reference, not a target. They tell you your order of magnitude. Your own trend matters more than any industry average. These reference points come from Atlassian's incident management research, the Google SRE handbook, and PagerDuty operations data, and they apply to severe, customer-facing incidents.

MTBF is deliberately different. It has no universal benchmark, because it depends entirely on how complex and critical your system is. A rising MTBF means you are getting more stable. A declining one means you are accumulating instability that faster incident response will never fix. For MTBF, only the direction matters.

Which Metric Should You Improve First?

Tracking four metrics is pointless if you try to improve all of them at once. Use a simpler rule. Call it the bottleneck-first method: find the single phase eating the most time, fix its lever, then re-measure before touching anything else.

It runs in three steps. First, break one representative incident into its phases: detect, acknowledge, diagnose, fix, verify. Second, find the fattest slice. Third, pull the matching lever and only that one.

The teams that plateau are the ones that over-optimize one phase and ignore the rest. If your diagnosis is already eight minutes but detection is fifteen, hiring faster engineers does nothing. The bottleneck is your monitoring. Measure first, then fix the thing that is actually slow.

Frequently Asked Questions

Further Reading