MTTR

MTTR is a reliability metric. You take every incident over a period, add up how long each one took to recover from, and divide by the number of incidents. If you had 4 outages last quarter that took 10, 20, 30, and 40 minutes to fix, your MTTR is 25 minutes.

The clock usually starts when the failure is detected, not when the customer first felt it, and stops when the service is fully restored. That detection gap matters: if your monitoring takes 15 minutes to notice a problem, that delay is often tracked separately as MTTD (Mean Time To Detect). Some teams measure MTTR from the moment of failure instead of detection, so always check which definition a team is using before comparing numbers.

The letters get reused for several related ideas. Recovery and Repair are the two common readings of the second R, and people also talk about Mean Time To Respond and Mean Time To Resolve. They are not the same. Repair counts only the hands-on fixing time; Recovery includes everything from alert to service restored. Pick one definition and stick to it.

MTTR is mostly an operations and automation problem, not a code problem. The biggest wins come from cutting the time spent figuring out what broke, not the time spent typing the fix. Good observability, clear dashboards, and alerts that point at the real cause shrink the investigation phase, which is usually where the minutes pile up.

Automation is the next lever. Health checks that auto-restart a crashed container, load balancers that pull an unhealthy node out of rotation, and orchestrators like Kubernetes that reschedule failed pods all recover without a human in the loop. The fastest recovery is the one nobody had to wake up for. When humans are needed, tested runbooks turn a 40 minute scramble into a 5 minute checklist.

The other half is making rollback cheap and instant. If a bad deploy can be reverted with one command or an automatic canary rollback, recovery is near-instant. Blue-green deploys, feature flags you can flip off, and immutable infrastructure all exist largely to make MTTR small.

MTTR pairs with MTBF (Mean Time Between Failures) to describe reliability. Availability is roughly MTBF divided by MTBF plus MTTR, so you can hit a high uptime number two ways: fail rarely, or recover fast. For most internet services, investing in fast recovery is cheaper and more realistic than trying to never fail, because failures are inevitable at scale.

The metric has sharp edges. An average hides the worst cases, so one 6 hour outage buried among many quick fixes can look fine on paper while having burned your customers. Tracking the median and the worst-case alongside the mean gives a truer picture. A small sample size also makes MTTR noisy: with only three incidents, a single bad one swings the whole number.

Chasing MTTR too hard can backfire. Teams under pressure to mark incidents resolved fast may slap on a quick workaround instead of a real fix, which leads to the same outage next week. MTTR is most honest when paired with a real postmortem process and a count of repeat incidents.

Say a payments API starts returning 500 errors at 2:14 because a new build has a bad config. Monitoring fires a PagerDuty alert at 2:16 (MTTD is 2 minutes). The on-call engineer opens the dashboard, sees error rate spiking right after a deploy, and triggers an automated rollback at 2:21. Traffic recovers by 2:24. MTTR for this incident is 8 minutes measured from detection.

Now imagine the same outage without good tooling: no deploy correlation on the dashboard, no one-click rollback, and the engineer has to SSH into boxes to read logs. The same root cause could take 45 minutes to find and fix. Same failure, same code, but MTTR is five times worse purely because of the recovery process.

This is why companies report MTTR in their SRE programs and tie it to error budgets. Google's SRE practice popularised the idea that you should engineer for fast, automated recovery rather than assume failures won't happen.