# Failed deployment recovery time

> **Note:** New to DORA? Start with [What is DORA?](/docs/engineering-delivery/what-is-dora), a five minute introduction that assumes no prior knowledge.

Failed deployment recovery time is how long it takes to get things working again after a deployment goes wrong. It is one of the five DORA metrics, it replaced the older measure called MTTR, and it tells you how long your users live with a broken release.

## What is failed deployment recovery time?

DORA defines it as:

> "The time it takes to recover from a deployment that fails and requires immediate intervention."

In plain words: a change went live, it broke something for users, and someone had to step in. The clock starts when that broken [deployment](/docs/engineering-delivery/glossary#deployment) goes live and stops when users are back to a working service.

Recovering usually means one of two things:

- a [rollback](/docs/engineering-delivery/glossary#rollback): putting the previous working version back, or
- a [hotfix](/docs/engineering-delivery/glossary#hotfix) or fix forward: shipping a quick new change that repairs the problem.

Our example team of six, building an online booking app, deployed a change on Tuesday at 14:00 that broke payment confirmation emails. A customer reported it at 14:40, the on-call developer rolled back at 15:10, and emails flowed again by 15:15. The recovery time for that failed deployment was 1 hour 15 minutes.

### From MTTR to failed deployment recovery time

You may know the older name, [MTTR](/docs/engineering-delivery/glossary#mttr): mean time to recover, or mean time to restore. DORA's metrics guide explains that, as the metrics evolved from the original four keys to the current five, failed deployment recovery time took the place of MTTR (DORA metrics guide).

The new name is narrower, and that is useful. MTTR was commonly used for recovery from any outage, including ones a delivery team has little control over, such as a cloud provider going down. Failed deployment recovery time only looks at failures caused by your own deployments. That makes it a measure of your delivery process: how quickly you can notice a bad change and undo or repair it.

### Why it counts as throughput

DORA groups the five metrics in two families. Since the 2024 report, failed deployment recovery time sits with the **throughput** metrics, next to [deployment frequency](/docs/engineering-delivery/deployment-frequency) and [change lead time](/docs/engineering-delivery/change-lead-time) (2024 report, p.11; 2025 report, p.13). That can be surprising, because it is about failures. DORA's reasoning is that throughput "measures the speed of making updates of any kind, normal changes and changes in response to a failure" (2024 report, p.12). A recovery is just another change, made under pressure. A team that can ship a normal change in an hour can usually ship a fix in an hour too.

## Why does it matter?

- **It is how long customers suffer.** Every minute a broken release stays live, users hit errors, lose work or leave.
- **Failures will happen.** No team deploys perfectly. What separates strong teams is not that they never break things, but that they recover quickly.
- **Fast recovery makes deploying less scary.** If you know you can undo a bad change in five minutes, you are more willing to deploy small changes often. That improves the other metrics too.
- **It tests your whole system.** Recovery needs good monitoring to notice the problem, a clear owner to act, and a deployment process fast enough to ship the fix.

## How do you measure it?

For each deployment that failed and needed immediate intervention, take the time from that deployment going live to the moment service was restored. Then take the [median](/docs/engineering-delivery/glossary#median) across all the failed deployments in a period.

**Why the median?** Recovery times vary a lot. Most failures may be fixed in under an hour, while one tricky problem takes two days. An average would be pulled up by that one case. The median shows what a typical recovery looks like.

You can get the data in two ways:

- **From deployments.** Find each deployment that was rolled back or hotfixed, and measure from it to the change that fixed it.
- **From incidents.** If your team records [incidents](/docs/engineering-delivery/glossary#incident) in a tool such as PagerDuty or Jira Service Management, each incident has an opened and a resolved time. The time between them is the time to restore.

The deployment route works without extra tools. The incident route is closer to what users experienced, because it starts when the problem was noticed and ends when service was actually restored. Pick one, say which you use, and keep it consistent.

> **Note:** Only failed deployments count. If no deployment failed this month, there is nothing to measure, and that is a good month.

## What does good look like?

The 2024 DORA report found four performance levels (2024 report, p.13):

| Level | Failed deployment recovery time | Share of respondents |
| --- | --- | --- |
| Elite | Less than one hour | 19% |
| High | Less than one day | 22% |
| Medium | Less than one day | 35% |
| Low | Between one week and one month | 25% |

The 2025 report shows how all respondents answered (2025 report, p.21):

| Failed deployment recovery time | Share of respondents |
| --- | --- |
| Less than one hour | 21.3% |
| Less than one day | 35.3% |
| Between one day and one week | 28% |
| Between one week and one month | 9.4% |
| Between one month and six months | 4.9% |
| More than six months | 1% |

So 56.5% of respondents recovered within a day.

The gap between the best and the rest is large. In 2024, elite performers had "2293x faster failed deployment recovery times" than low performers (2024 report, p.15). Even so, DORA's advice holds: compare a service with its own past, and value improvement over reaching a level. See [DORA performance levels](/docs/engineering-delivery/performance-levels#the-2024-performance-levels).

## How do you improve it?

1. **Make rolling back one step.** If undoing a deployment needs a meeting and a manual procedure, recovery will be slow. A tested, one-click (or automatic) rollback is one of the strongest levers you have. DORA's 2025 research also found that teams proficient with rollback and revert get more out of AI-assisted development (DORA AI Capabilities Model).
2. **Notice problems quickly.** You cannot fix what you have not seen. [Monitoring and observability](https://dora.dev/capabilities/monitoring-and-observability/) and [proactive failure notification](https://dora.dev/capabilities/proactive-failure-notification/) alert you before customers have to tell you.
3. **Keep changes small.** When a deployment holds one small change, the cause of a problem is obvious. When it holds two weeks of work, finding it takes hours. See [working in small batches](https://dora.dev/capabilities/working-in-small-batches/).
4. **Make the deployment path fast.** A fix forward can only be as fast as your normal pipeline. [Deployment automation](https://dora.dev/capabilities/deployment-automation/) and quick [continuous integration](https://dora.dev/capabilities/continuous-integration/) help here.
5. **Use feature flags.** A [feature flag](/docs/engineering-delivery/glossary#feature-flag) lets you switch off a broken feature without deploying anything at all.
6. **Learn from each recovery.** After a failure, write down what slowed the recovery: was it noticing, deciding, or shipping? Then fix that one thing. Keep these reviews blameless, so people share what really happened.

## Common mistakes

- **Counting every outage.** Recovery from a cloud provider failure says little about your delivery process. Failed deployment recovery time is about your own deployments.
- **Using the average.** One long recovery will distort it. Use the median.
- **Stopping the clock too early.** A fix that is merged but not yet live has not restored anything.
- **Forgetting it needs context.** A short recovery time is less impressive if the same thing keeps breaking. Read it next to [change fail rate](/docs/engineering-delivery/change-fail-rate) and [deployment rework rate](/docs/engineering-delivery/deployment-rework-rate).
- **Blaming individuals.** Slow recovery is almost always a system problem: missing alerts, unclear ownership or a slow pipeline.

## How Solidafy measures it

In the Engineering Delivery app:

- By default, recovery time is the median time from a release that needed intervention (rolled back or hotfixed) to the change that fixed it, over the period you choose.
- When you connect an incident source in Settings (Jira, Linear or PagerDuty), it uses the median time to restore of the resolved incidents opened in the period instead, and the tile says which method it is using.
- The default goal comes from your own baseline: 10% better than your current value, once the app has measured it. DORA's 2025 report publishes no target, so no published figure is used. You can accept the default, edit it, or set your own goal. A default is a suggestion, never a grade, and it never raises an alert on its own.
- The Incidents section shows where incidents happen, by service, with the median time to restore those resolved.
- Figures are per team and per service. Nothing is estimated, and no one is named.

You find recovery time on the Overview, on the **Speed** page and on the **Incidents** page; the [Speed guide](/docs/engineering-delivery/speed) and the [Incidents guide](/docs/engineering-delivery/incidents) explain how to read it and recover faster.

## Learn more

From DORA:

- [DORA's software delivery performance metrics](https://dora.dev/guides/dora-metrics/)
- [Accelerate State of DevOps Report 2024](https://dora.dev/research/2024/dora-report/)
- [State of AI-assisted Software Development 2025](https://dora.dev/research/2025/dora-report/)
- [DORA AI Capabilities Model](https://dora.dev/ai/capabilities-model/report/)
- Capabilities: [monitoring and observability](https://dora.dev/capabilities/monitoring-and-observability/), [proactive failure notification](https://dora.dev/capabilities/proactive-failure-notification/), [deployment automation](https://dora.dev/capabilities/deployment-automation/)

Related Solidafy guides:

- [The five DORA metrics](/docs/engineering-delivery/dora-metrics)
- [Change fail rate](/docs/engineering-delivery/change-fail-rate)
- [Deployment rework rate](/docs/engineering-delivery/deployment-rework-rate)
- [Improving software delivery](/docs/engineering-delivery/overview-and-focus)