Skip to main content
Back to KPI Library
Engineering

What is Mean Time to Recovery?

Average time to restore service after an incident.

How to calculate it

Calculate Mean Time to Recovery as: Total downtime / Number of incidents. Pull the inputs from your connected data and track the trend over time in your dashboard.

Examples

Example 1

120 minutes total downtime across 4 incidents -> 30-minute MTTR.

Example 2

120 minutes of total downtime across 4 incidents -> 30-minute MTTR, within the elite range thanks to good alerting and runbooks.

Why it matters

Mean time to recovery (MTTR) is the average time to restore service after an incident and is a DORA measure of resilience. Fast recovery limits the customer and revenue impact of inevitable failures. Excluding detection time understates true MTTR and can mask slow alerting.

Benchmark context

Elite teams recover in under one hour; longer recovery times point to gaps in monitoring, runbooks or on-call processes.

Common pitfalls

Excluding detection time.

The complete guide

Understanding Mean Time to Recovery

Mean time to recovery (MTTR) is the average time to restore service after an incident and is a DORA measure of resilience. Fast recovery limits the customer and revenue impact of inevitable failures. Excluding detection time understates true MTTR and can mask slow alerting. For context, elite teams recover in under one hour; longer recovery times point to gaps in monitoring, runbooks or on-call processes. Treat an external benchmark as a reference point rather than a universal target: company stage, sector, customer mix, pricing model and measurement definitions can materially change what “good” looks like. Read Mean Time to Recovery alongside Change Failure Rate and Uptime; together these measures provide a more balanced view and reduce the risk of optimizing one number at the expense of the wider outcome.

Make sure the numerator and denominator cover compatible populations and periods, and avoid dividing by a partial or unusually small base. Use stable production boundaries and timestamp definitions, and distinguish planned work from incidents, rollbacks and failed deployments. Measure at service or team level and keep the start event, end event and production boundary stable; portfolio averages can hide a fragile component. A dashboard should show the current value, prior-period comparison and a trend rather than presenting one isolated reading.

Treat the metric as a prompt for system improvement: reduce batch size, automate safe delivery, strengthen observability, rehearse recovery and use blameless reviews to eliminate recurring failure modes. Common pitfalls: excluding detection time. Record the definition beside the dashboard, review it when systems or processes change, and annotate unusual events so future readers can distinguish a genuine performance shift from a data or timing effect.

Sources and further reading

  1. Common incident management metrics

    Atlassian Accessed

Related KPI guides

Turn KPI definitions into governed dashboards

Metricwise helps teams define metrics once, reuse them across dashboards, and ask trusted business questions in plain English.

Get Started