Skip to content

Ledger entryNo. 983508

Mean Time to Recovery(MTTR)

Also called: Mean time to restore · Mean time to repair · Time to restore service

Definition
The average time from the start of an incident to service being restored for customers: a measure of how fast a team detects, responds and recovers.

Reliability & scale

Mode · timeline

Work it out

Scrub through one incident: where do the minutes go?

7 / 7

Next dayEvent 7 of 7

Postmortem

Action item: a CI contract test that verifies a signed sample webhook before every deploy.

One illustrative webhook outage, minute by minute. Detection took 7 minutes and the fix shipped at minute 22, but recovery ended only at minute 49, once Meta's retried events were processed. MTTR averages this full span across incidents.

Event 7 of 7: Next day — Postmortem. Action item: a CI contract test that verifies a signed sample webhook before every deploy.

What is MTTR (mean time to recovery)?

Mean Time to Recovery (MTTR) is the average time it takes to restore service after a failure begins. Add up the duration of every incident in a period, from the moment customers were affected to the moment they no longer were, and divide by the number of incidents. Four incidents lasting 18, 42, 95 and 25 minutes give 180 ÷ 4, an MTTR of 45 minutes.

The letters are overloaded, so define them before you report them. Teams use MTTR to mean time to recovery, restore, repair, respond or resolve, and each starts or stops the clock at a different point. It is usually read with its parts and siblings: MTTD (mean time to detect, from failure to alert), MTTA (mean time to acknowledge, from alert to a person working on it) and MTBF (mean time between failures, how often things break). MTTR says how long each failure hurts; MTBF says how often failures happen.

MTTR is a backward-looking outcome of Incident Management. It differs from the recovery time objective (RTO) in Disaster Recovery planning, which is a target set in advance for the worst case. For a WhatsApp system, recovery should mean customers are whole again (OTPs arriving, and the webhook backlog that Meta's Webhook Retry Policy keeps re-delivering for up to seven days fully processed), not merely that a fix was deployed.

Key takeaways

  • MTTR is the total time to recovery across incidents divided by the number of incidents.
  • Four incidents lasting 18, 42, 95 and 25 minutes give an MTTR of 180 ÷ 4 = 45 minutes.
  • Define the clock: start when customers were first affected, stop when they are whole again, not when the fix ships.
  • Report the median and the worst incident beside the mean, because one long outage can dominate a small sample.
  • MTTR is measured after the fact; RTO in disaster recovery is a target set in advance.

The figures

MTTR (mean time to recovery): key facts and limits

Formula
Total time to recovery ÷ number of incidents
Worked example
(18 + 42 + 95 + 25) ÷ 4 = 45 minutes
MTTD
Failure start to detection
MTTA
Detection to a person acknowledging
MTBF
Average time between failures
Not the same as
RTO, a recovery target set in advance
Clock stops when
Customers are whole and the backlog has drained

Example: One outlier, one real fix

A Bengaluru lending app logs five incidents in a quarter, lasting 12, 9, 31, 14 and 184 minutes. Its MTTR is 250 ÷ 5 = 50 minutes, yet four incidents were under 35 minutes and the median is 14. The 184-minute outlier was a webhook outage: the fix shipped at minute 40, but Meta's retried events took another 144 minutes to process because the workers were sized for normal traffic. The change that cut MTTR most was not faster debugging but autoscaling the webhook workers on queue age.

How does MTTR (mean time to recovery) work?

  1. Timestamp every incident the same way

    Record when impact started, and when it was detected, acknowledged, mitigated and fully recovered. Place the start from customer-facing signals such as failed sends or webhook errors, not from when someone noticed.

  2. Compute the mean, and the median

    MTTR = total time to recovery ÷ number of incidents. Report the median and the worst incident as well, because one long outage can dominate a quiet quarter's average.

  3. Break it into phases

    Split each incident into detect, acknowledge, diagnose and recover. The phase that is longest across incidents is where improvement pays off most.

  4. Shrink detection

    Alert on symptoms customers feel (OTP success rate, the webhook 200 rate, the age of the oldest job in the send queue), and use synthetic checks so that silence is caught too.

  5. Shrink repair

    Make rollback a single command, keep runbooks for the top failure modes (expired token, paused template, endpoint down), and keep backup templates approved so mitigation never waits for review.

In code

MTTR (mean time to recovery) in code

-- incidents(id, severity, started_at, detected_at, acknowledged_at, mitigated_at, recovered_at)
SELECT
  date_trunc('quarter', started_at)                                       AS quarter,
  count(*)                                                                 AS incidents,
  round((avg(extract(epoch FROM recovered_at - started_at)) / 60)::numeric, 1)    AS mttr_min,
  round((percentile_cont(0.5) WITHIN GROUP
         (ORDER BY extract(epoch FROM recovered_at - started_at)) / 60)::numeric, 1) AS median_min,
  round((avg(extract(epoch FROM detected_at - started_at)) / 60)::numeric, 1)     AS mttd_min,
  round((avg(extract(epoch FROM acknowledged_at - detected_at)) / 60)::numeric, 1) AS mtta_min,
  round((max(extract(epoch FROM recovered_at - started_at)) / 60)::numeric, 1)    AS worst_min
FROM incidents
WHERE severity IN ('SEV1', 'SEV2')
GROUP BY 1
ORDER BY 1;

MTTR beside its median, MTTD, MTTA and the worst incident, per quarter, for the severities that matter.

Why does MTTR (mean time to recovery) matter?

MTTR is the reliability number a business feels most directly. If OTP sends fail for 45 minutes, logins fail for 45 minutes; halving MTTR halves that damage even if failures happen just as often. It also shows where to invest. A long MTTD says Alerting and Observability are weak; a long gap between acknowledgement and mitigation says runbooks or rollbacks are missing. Both are usually cheaper to fix than preventing every possible failure, and every minute saved also stops draining the Error Budget.

Costly mistakes

Common mistakes with MTTR (mean time to recovery)

  • Stopping the clock at the deploy

    A fix in production is not recovery while Meta is still re-delivering hours of webhooks or the send queue is still draining. Stop the clock when customer-facing signals are back to normal.

  • Trusting the mean alone

    With a handful of incidents, one long outage swings the average wildly. Report the median, the worst case and the incident count next to MTTR.

  • Starting the clock at the alert

    Measuring from detection hides slow detection, which is often the longest phase. Start from when impact began, using your metrics after the fact.

  • Mixing definitions

    Comparing one team's time to resolve with another team's time to restore compares different things. Write down which timestamps start and stop the clock.

  • Gaming the number

    Splitting one long incident into several short ones, or not declaring small ones, makes MTTR look better while customers fare worse. Review the incidents, not just the metric.

Best practices for MTTR (mean time to recovery)

  • Track MTTD and MTTA next to MTTR; detection is usually the cheapest phase to shrink.
  • Rehearse your top three runbooks until the recovery steps are routine.
  • Report MTTR per severity: a SEV1 average mixed with SEV4 noise means little.
  • Count backlog drain as part of recovery, and size workers for post-outage catch-up, not just normal traffic.

MTTR FAQs

How do you calculate MTTR?
Divide the total time to recovery by the number of incidents. For example, incidents lasting 18, 42, 95 and 25 minutes total 180 minutes, and 180 ÷ 4 gives an MTTR of 45 minutes.
What is the difference between MTTR and MTBF?
MTTR measures how long failures last; MTBF measures how long the system runs between them. Together they describe reliability: you improve it by failing less often (raising MTBF) or by recovering faster (lowering MTTR).
Is MTTR the same as RTO?
No. MTTR is measured afterwards across real incidents, while RTO (recovery time objective) is a target set in advance for how quickly a system must come back after a disaster.
What is a good MTTR?
It depends on the service; the trend matters more than any benchmark. For customer-facing flows such as OTP delivery, aim to restore your most severe incidents within an hour, and check that MTTR falls from quarter to quarter.

See InfiQ pricing

Put MTTR to work

InfiQ is an official Meta Business Partner. Start a 7-day free trial — no card needed — and see this running on your own number.

Start free trialBrowse all 550 terms