Mean Time To Recover (MTTR) Report

Last updated: October 27, 2026

Mean time to recover (MTTR) shows how long your incidents last, from start to resolution. It sits on the DORA page next to deployment frequency, lead time for changes, and change failure rate.

Why it matters

Lower MTTR means customers feel an outage for less time, and your teams lose less time to firefighting and get more of it back for planned work. MTTR tells you:

  • Incident response speed: how quickly teams detect, diagnose, and fix production problems.

  • Team readiness: how well your on-call rotation, runbooks, and escalation paths work.

  • Business impact: how long customers live with an outage or degraded service.

Read MTTR next to Incidents / week and Change failure rate:

  • High MTTR and many incidents: system instability. Focus on resilience.

  • High MTTR and few incidents: a slow response process. Focus on runbooks and on-call.

  • Low MTTR and many incidents: you recover well but break often. Focus on prevention and quality.

  • Low MTTR and few incidents: strong reliability. Keep it there.

How it works

For each incident, Span subtracts the start time from the resolution time:

Time to recover = resolved time − start time

Incident source

Start time

End time

incident.io

When the incident was created in incident.io

The incident's latest "Resolved at" time

Rootly

When the incident was created in Rootly

The incident's resolved time

DORA API

The startedAt you send

The endedAt you send

Span then combines every incident created in your date range, even if it resolved later. You can view the result as:

  • Average: a plain mean of every incident, with no cap or trimming.

  • P50 (median): half your incidents resolve faster, half slower.

  • P75 and P90: how long your slower incidents take.

  • Max: the longest incident in the range.

Span measures wall-clock time, so nights and weekends count. Incidents come from incident.io, Rootly, or Span's DORA API. Span has no PagerDuty or Opsgenie connector; teams on those tools send incidents through the DORA API.

Teams. Span credits each incident to its owner teams: the incident.io team field you map, your Rootly team mappings, or the owners you send through the API. Incidents with no owner team count in your organization total only. MTTR has no per-person view.

Where to find it. Go to Insights → Productivity → DORA and open the Mean time to recover chart. Filter by team or date range. To see the incidents behind a number, go to Catalog → Incidents.

Setup

  1. Connect incident.io or Rootly in Settings → Integrations, or send incidents to Span through the DORA API.

  2. Map incidents to teams: pick the team field in the incident.io integration, map Rootly teams to Span teams, or send owners on API incidents.

  3. If you use the DORA API, send startedAt and endedAt on every incident. Without startedAt, the incident counts as 0.

  4. Open Insights → Productivity → DORA and check the Mean time to recover chart.

Things to know

  • Open incidents count as 0. An incident with no resolution time yet adds 0 hours to MTTR, which pulls the average and percentiles down. Check Catalog → Incidents for incidents that never got a resolved time.

  • API incidents without startedAt also count as 0. Send startedAt on every incident, or add it later with a PATCH.

  • For incident.io and Rootly, the clock starts when the incident is created. If impact began before anyone declared the incident, Span's MTTR is shorter than the real outage. If an incident sat in triage, Span's MTTR is longer. Your incident tool's own MTTR may start at a different time, such as "Impact started" or "Accepted at", so the numbers won't always match.

  • MTTR counts incidents in every environment. Total incidents and Change failure rate count production incidents only. An API incident sent with environment: staging shows in MTTR but not in those two metrics. incident.io and Rootly incidents carry no environment.

  • Every status and severity counts. Span doesn't filter out declined, canceled, or low-severity incidents.

  • Use percentiles for planning. One multi-day incident lifts the average. P50 shows the typical incident, and P90 shows how long 90% of incidents take to resolve.

  • Older DORA setup. If Span set your organization to the older version of the DORA page, MTTR uses Jira issues that match your critical-bug rules, measured from creation to completion, and open issues drop out.

  • Worked example. Three incidents are created this week. Incident A runs 1.5 hours, incident B runs 6 hours, and incident C is still open. Average MTTR is (1.5 + 6 + 0) ÷ 3 = 2.5 hours, and P50 is 1.5 hours. When C resolves after 4 hours, the average becomes (1.5 + 6 + 4) ÷ 3 ≈ 3.8 hours.

Acting on MTTR. Open your slowest incidents in Catalog → Incidents and look for patterns by service, time of day, or team. Compare teams to find practices worth sharing. Common levers are better runbooks, clearer alerts and dashboards, clear escalation paths, and blameless postmortems. Set targets from your own baseline (P50 and P90), track the trend over a quarter, and don't use MTTR to blame teams.

Related articles

Understanding the Mean Time to Recover (MTTR) Chart

Change Failure Rate Report

How does the Incident.io integration work?

Rootly Integration

How to use the DORA API to send deployment activity to Span

Need help?

Contact your Span account team or reach out to support@span.app.