---
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
---

# Incident Metrics Explained: MTTR, MTTD, MTBF and friends

2026-05-16 · WatchFor Team · Reliability · incidents, reliability, sre

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.

---

Canonical page: https://watchfor.io/blog/incident-metrics-mttr-mttd-mtbf · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt