--- title: Incident Metrics Explained: MTTR, MTTD, MTBF and friends description: MTTR, MTTD, MTBF, MTTA — the alphabet soup of incident metrics, explained in plain English. What each measures, how to calculate it, and how to actually improve the numbers. canonical: https://watchfor.io/blog/incident-metrics-mttr-mttd-mtbf --- [All posts](/blog) [Reliability](/blog/category/reliability) May 16, 2026 · 3 min read · WatchFor Team # Incident Metrics Explained: MTTR, MTTD, MTBF and friends MTTR, MTTD, MTBF, MTTA — the alphabet soup of incident metrics, explained in plain English. What each measures, how to calculate it, and how to actually improve the numbers. "So, how fast do we recover when something breaks?" It's a fair question from a manager, an exec, or a customer — and "uh, pretty fast usually?" is not a great answer. The grown-up answer is a number, and that number has a name: MTTR . It's one of a small family of incident metrics that turn "we're reliable, trust us" into something you can actually measure and improve. Here's the whole alphabet soup, decoded. ## The metrics, decoded Each one measures a different slice of an incident's life. The "MTT" ones all mean Mean Time To something : Metric Stands for Measures Lower is better? MTTD Mean Time To Detect Problem starts → you notice ✅ Yes MTTA Mean Time To Acknowledge Alert fires → a human owns it ✅ Yes MTTR Mean Time To Recovery/Repair Incident starts → service restored ✅ Yes MTBF Mean Time Between Failures Average uptime between incidents ❌ Higher is better MTTF Mean Time To Failure Lifespan of a non-repairable thing ❌ Higher is better The first three (MTTD, MTTA, MTTR) measure how well you respond . The last two (MTBF, MTTF) measure how often things break in the first place. ## How an incident breaks down in time These metrics aren't separate — they're stages of the same timeline: Problem starts ──► Detected ──► Acknowledged ──► Recovered └── MTTD ──┘ └─ MTTA ─┘ └────────────── MTTR ──────────────────┘ MTTR is the headline because it's the whole journey: from the moment things break to the moment they're fixed. And notice — MTTD is part of MTTR. If it takes you an hour to even notice an outage, your recovery time can never be under an hour, no matter how fast your fix is. ## How to calculate them The maths is simple — average the relevant durations over a period: - MTTR = total downtime from incidents ÷ number of incidents. (Five incidents totalling 100 minutes of downtime → MTTR = 20 minutes.) - MTBF = total operating time ÷ number of failures. (720 hours in a month, 4 failures → MTBF = 180 hours.) Watch the average. "Mean" hides outliers. Four 5-minute incidents and one 3-hour outage average out to a respectable-looking MTTR — while completely hiding the 3-hour disaster. Look at the distribution, not just the mean (the same lesson as [latency percentiles](/blog/latency-percentiles-p99)). ## How to actually improve each one Numbers are only useful if you can move them. Here's the lever for each: To improve… Do this MTTD (detect faster) Better monitoring: frequent checks, multiple locations, alert on symptoms MTTA (acknowledge faster) Clear [on-call](/blog/on-call-best-practices) + escalation; cut [alert noise](/blog/alert-fatigue) so real alerts get seen MTTR (recover faster) Runbooks, fast rollback, good [root-cause](/docs/alerting/root-cause) info, practice MTBF (break less often) Fix root causes (via [postmortems](/blog/blameless-postmortem)), add redundancy, reduce risky changes The single highest-leverage move? Lower MTTD. Faster detection shrinks MTTR directly and limits the damage — and it's the cheapest to improve, because it's mostly about good monitoring. ## Common pitfalls - Gaming the numbers. If "resolved" is declared the moment a fix is deployed (not when it's confirmed working), MTTR looks great and means nothing. - Averages hiding pain. As above — always check the worst cases, not just the mean. - Metrics as a stick. Use them to improve systems, not to punish people. (See [blameless postmortems](/blog/blameless-postmortem).) - Measuring everything, improving nothing. Pick one or two to focus on per quarter. ## The bottom line Metric One line MTTD How fast you notice. Improve this first. MTTA How fast someone takes ownership. MTTR The headline: total time to recover. MTBF How long between failures — higher is better. Incident metrics turn reliability from a feeling into a number you can track and improve. Start by measuring MTTD and MTTR honestly, lean on monitoring to push them down, and use the trend — not a single month — to tell whether you're actually getting better. It all starts with detecting faster — which is what [uptime monitoring](/blog/uptime-monitoring-101) and good [alerting](/docs/alerting) are for. [#incidents](/blog/tag/incidents)[#reliability](/blog/tag/reliability)[#sre](/blog/tag/sre) ## Manage incidents with WatchFor Confirmed incidents with a clear lifecycle, full timeline, root cause and private team notes — so you resolve faster. [Learn more](/incident-management)[Start free](/auth/sign-up) Share this article --- Canonical page: https://watchfor.io/blog/incident-metrics-mttr-mttd-mtbf · Site guide: https://watchfor.io/llms.txt