MTTD, MTTA, MTTR, MTBF — Reliability Metrics Without the Buzzword Soup

Reliability conversations have a vocabulary problem. Someone says "our MTTR is four hours," someone else asks whether that includes detection time, a third person quietly wonders if the R stands for repair, recovery, respond or resolve — and it turns out all three of them are tracking different numbers under the same name.

The metrics themselves are genuinely useful. They're just buried under acronym soup and misused averages. This post defines the four that matter — MTTD, MTTA, MTTR, MTBF — walks one realistic incident through all of them, and then covers the two things most write-ups skip: why the "mean" in each of these can lie to you, and which of the four is cheapest to actually improve.

The four metrics, in the order an incident happens

Every incident has the same skeleton: something breaks, someone finds out, someone starts working, it gets fixed. Each metric measures one gap in that chain.

• MTTD — Mean Time To Detect. From the moment the failure starts to the moment your systems (or a human) know about it. This is where monitoring lives or dies: with 5-minute check intervals and no alerting, your MTTD is however long it takes a customer to email you.
• MTTA — Mean Time To Acknowledge. From the alert firing to a human saying "I'm on it." This measures your alerting pipeline and on-call reality: an alert that sits unacknowledged for 25 minutes was, for 25 minutes, indistinguishable from no alert.
• MTTR — Mean Time To Recovery. From failure start to service restored for users. The R gets expanded many ways (repair, resolve, respond); pick recovery, define it as "users are fine again," and write your definition down — the metric is worthless if two people on the same team compute it differently. Note that MTTR contains detection and acknowledgement: you cannot fix what you haven't found.
• MTBF — Mean Time Between Failures. The average stretch of healthy operation between incidents. Where the other three measure how well you respond, MTBF measures how often you have to — it's the prevention metric, moved by root-cause fixes, redundancy and deploy discipline rather than by faster firefighting.

A worked example: one Tuesday outage

Here's a realistic timeline for a small SaaS whose API died behind a connection-pool leak:

02:14  API starts returning 500s            (failure begins)
02:16  Monitor confirms failure, alert fires     → MTTD:  2 min
02:24  On-call engineer acks the page            → MTTA:  8 min
02:31  Cause identified: connection pool exhausted
02:47  Service restarted, pool limits raised,
       checks green                              → MTTR: 33 min

Read the gaps, not just the totals. Detection took 2 minutes — the monitoring did its job. Acknowledgement took 8 — the engineer was asleep, phone on vibrate; that's an escalation-policy problem, not a monitoring problem. Diagnosis and fix took 23 — that's where runbooks and better dashboards would pay off.

And if the previous incident ended 19 days earlier, your MTBF is roughly 19 days — a separate fact that tells you whether Tuesdays like this are rare or a lifestyle.

The point of splitting one 33-minute outage into named segments is that each segment has a different owner and a different fix. "Get faster at incidents" is not actionable. "Our MTTA is a third of our MTTR and it's pure phone-on-vibrate" is.

Why averages mislead — the 6-hour outage problem

Now the trap. Consider two services over a quarter:

• Service A: six incidents, each lasting 1 minute. MTTR: 1 minute. Total downtime: 6 minutes.
• Service B: one incident lasting 6 hours. MTTR: 360 minutes. Total downtime: 6 hours.

Same incident count ballpark, wildly different customer experience — and the averages invert the story you'd tell. Service A's tiny MTTR looks heroic but might reveal a flapping system failing constantly and self-healing; Service B's terrible MTTR came from a single unlucky night. A mean compresses all of that into one number that flatters whoever has more small incidents.

Practical corrections:

• Always read MTTR next to total downtime and incident count. One number without the others is a story with the ending torn out.
• Look at the distribution, not the mean. Median and worst-case tell you more. One 6-hour outage averaged with six 1-minute blips yields ~52 minutes — a number that describes none of your actual incidents.
• Segment by severity. Averaging a full outage with a "one region was slow" degradation produces a metric nobody can act on.
• Beware Goodhart's law. Teams told to lower MTTR discover creative incident definitions. The metric is a flashlight, not a target.

The cheapest MTTR win is almost always detection

Here's the observation that makes this whole topic practical: MTTR is a sum — detect + acknowledge + diagnose + fix — and the segments differ enormously in how much they cost to shrink.

Cutting diagnosis-and-fix time means better tooling, runbooks, architecture work, practice. Worthwhile, and expensive. Cutting detection time means checking more often and alerting properly — configuration, not engineering.

Run the math on the Tuesday incident with lazier monitoring: 10-minute check intervals and email-only alerts could plausibly have meant detection at 02:24 and acknowledgement whenever someone woke up — the same 23 minutes of actual fixing wrapped in an hour of nobody-knows-yet. Same team, same skills, triple the outage. By some estimates a large share of total downtime at small teams is exactly this: time when the thing was broken and nobody knew. Tight check intervals, confirmed alerts, and a channel that actually interrupts someone routinely take MTTD from tens of minutes to about one — the biggest single bite anyone ever takes out of MTTR, for the least effort.

Track them from data you already have

You don't need a metrics platform — you need timestamps. Failure start and detection come from your monitoring history; acknowledgement from your alerting flow; recovery from when checks went green. A spreadsheet with four columns per incident, reviewed monthly, beats a dashboard nobody defined honestly. Watch trends, not absolutes: MTTD creeping up means monitoring has gaps; MTTA creeping up means on-call is fraying; MTBF shrinking means you're accumulating reliability debt.

CompleteStatus gives you the raw material automatically — every incident recorded with when it started, when it was confirmed, when it recovered, and how long it lasted, across uptime, SSL, DNS and heartbeat checks in one dashboard. Detection — the cheapest segment to fix — is the product: frequent checks, confirmation before alerting, and notifications that reach a human fast. Create a free account and put real numbers on your next incident — you can't shrink a gap you've never measured.