Engineering Delivery
The five DORA metrics
The DORA metrics are five measures of how a team delivers software: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. The first three show how quickly changes flow to users (throughput), and the last two show how often releases cause trouble (instability). Read together, they tell you whether a team is getting faster and safer at the same time.
If you have never heard of DORA, start with What is DORA? first. This page assumes only that you know DORA is a research programme about software delivery.
The words you need first
Three everyday words carry most of the meaning on this page.
- A change is any edit to the software: a new feature, a bug fix, a configuration tweak. Developers save changes into version control, a shared history of every edit, usually Git. Saving a change there is called a commit.
- A deployment is the moment a change is put live. Some teams say release or ship.
- Production is the live system your real users use, as opposed to a test copy.
The five metrics at a glance
Each metric answers one question. The definitions in quotes are DORA's own, from its metrics guide.
| Metric | Group | DORA's definition | Better is |
|---|---|---|---|
| Change lead time | Throughput | "The amount of time it takes for a change to go from committed to version control to deployed in production." | Shorter |
| Deployment frequency | Throughput | "The number of deployments over a given period or the time between deployments." | More often |
| Failed deployment recovery time | Throughput | "The time it takes to recover from a deployment that fails and requires immediate intervention." | Shorter |
| Change fail rate | Instability | "The ratio of deployments that require immediate intervention following a deployment." | Lower |
| Deployment rework rate | Instability | "The ratio of deployments that are unplanned but happen as a result of an incident in production." | Lower |
A running example
We will use one imaginary team throughout. A team of six builds an online booking app. Over the last month they made 12 deployments. Each section below shows how one metric comes out for them.
Change lead time
Change lead time is how long a change takes to reach users once someone has committed it.
The clock starts when a developer commits the change to version control and stops when that change is running in production. Everything in between counts: waiting for someone to review it, automated tests, waiting for a release window, the deployment itself.
Example: the booking team's changes take 3 days from commit to production at the median. The median is the middle value when you line all the changes up from fastest to slowest, so half took less and half took more. It is used instead of an average because one change that sat for a month would drag an average up and hide what usually happens.
A long lead time means customers wait longer for fixes and features, and the team waits longer to learn whether a change worked. Most of it is usually waiting, not working. Read the change lead time guide.
Deployment frequency
Deployment frequency is how often a team puts changes live.
You count production deployments over a period, or look at the time between them. A team that deploys several times a day and one that deploys once a quarter work in very different ways.
Example: 12 deployments in a month is about three a week.
Frequent deployments usually mean small deployments, and small deployments are easier to test, easier to understand and easier to undo. Read the deployment frequency guide.
Failed deployment recovery time
Failed deployment recovery time is how long it takes to put things right after a deployment goes wrong.
It covers deployments that fail and need someone to step in straight away, for example to undo the release (a rollback) or ship an urgent fix (a hotfix). The clock runs from the bad deployment until users are back to a working service.
Example: two of the booking team's deployments went wrong this month. Each time it took about 2 hours to roll back.
This metric used to be called mean time to recovery (MTTR). DORA replaced it with failed deployment recovery time to focus on recovering from failures your own changes caused, rather than any outage at all. Read the failed deployment recovery time guide.
Change fail rate
Change fail rate is the share of deployments that need fixing straight away.
You divide the deployments that needed immediate intervention, such as a rollback or a hotfix, by all deployments in the period. DORA counts a deployment as failed only if the problem reaches production where users can experience it. A change stopped on its way to production, say by a failing test, is not a failure: it shows the safety checks working (2024 report, page 16).
Example: 2 of 12 deployments needed rolling back, so the change fail rate is about 17%.
Read the change fail rate guide.
Deployment rework rate
Deployment rework rate is the share of deployments that were not planned and only happened because of a problem in production.
These are the "we have to ship something now" releases that interrupt planned work. DORA added this metric in 2024, after testing its long-held idea that change fail rate stands in for how much rework a team is forced into. The survey question asks how many deployments in the last six months "were not planned but were performed to address a user-facing bug" (2024 report, page 11).
Example: 1 of the booking team's 12 deployments was not planned at all: it went out only to fix a bug customers reported in production. That is 1 in 12, about 8%.
Read the deployment rework rate guide.
Throughput and instability: why there are two groups
DORA groups the metrics into throughput and instability because the two can move independently, and you need to see both.
- Throughput measures, in DORA's words, "the speed of making updates of any kind, normal changes and changes in response to a failure" (2024 report, page 12). It is change lead time, deployment frequency and failed deployment recovery time.
- Instability (DORA used to say stability) measures "the likelihood deployments unintentionally lead to immediate, additional work" (2024 report, page 12). It is change fail rate and deployment rework rate.
Recovery time sits under throughput because it is about speed: how fast you can get a fix out. That surprises people who think of recovery as a stability topic, and it is a change from how the metrics used to be grouped.
More than half the teams in the 2024 study showed differences between their throughput and their stability (2024 report, page 11). A team can be fast but break things often, or careful but slow. The best teams do well on both, and DORA's 2025 report calls the speed versus stability trade-off a myth (page 19).
From four keys to five metrics
The DORA metrics have changed over time, which is why you will see older articles talk about "the four keys".
- For years DORA measured four key metrics: lead time for changes, deployment frequency, mean time to recovery (MTTR) and change failure rate.
- MTTR was replaced by failed deployment recovery time, which looks only at recovering from failed deployments.
- Deployment rework rate was added in 2024 as the fifth metric (2024 report, page 11).
Names vary a little between sources: "lead time for changes" and "change lead time" mean the same, as do "change failure rate" and "change fail rate".
How do you measure them in practice?
You can measure all five from tools most teams already have, as long as you agree first on what counts as a deployment.
Decide what a deployment is. For one team it is a production deployment run by its pipeline, for another a merge to the main branch that ships automatically, for a third a tagged release. Pick the definition that matches when users actually get the change, and keep it stable so numbers compare over time.
Know where each number comes from:
- Commits and merges come from your code host, such as GitHub or GitLab.
- Deployments come from your deployment pipeline or code host.
- Rollbacks and hotfixes show up as reverted changes, redeployed earlier versions or urgent fix deployments.
- Incidents come from an incident tool, such as PagerDuty or Jira Service Management. You need them for deployment rework rate, and they make recovery time more precise.
Measure one application or service at a time. DORA's guide says to use the metrics "in the context of the application or service your team is delivering". A team that owns three services should look at each.
Precision is less important than direction. DORA notes that teams usually know how their numbers are changing over time even without perfect data (2025 report, page 22). Start rough and improve the measurement as you go.
Common mistakes
DORA's metrics guide names four pitfalls, and they are worth knowing before you start.
- Setting the metrics as goals. When a measure becomes a target, it stops being a good measure, because people find ways to move the number without improving anything. This is known as Goodhart's law. A team told to "deploy more often" can split deployments into meaningless pieces.
- Having one metric to rule them all. Software delivery is too complex for one number. Look at all five together.
- Making disparate comparisons. Comparing very different applications, or very different teams, tells you little and invites blame.
- Having siloed ownership. The metrics belong to everyone involved in delivery: development, operations and release. If only one group owns them, the others stop caring.
Two more worth adding: never use the metrics to rate individual people, and do not hide behind a team average when one service is struggling.
How do you improve them?
You improve the metrics by improving the way the team works, one constraint at a time, not by pushing on the numbers.
DORA's suggested loop is simple: get a baseline (the free DORA Quick Check can help), map how a change gets to production, find the biggest constraint, commit to one improvement, then measure again and repeat. The improving software delivery guide walks through it, and finding your biggest constraint is the place to begin.
How Solidafy measures them
The Engineering Delivery app reads the five metrics from your connected tools and shows them per team, or per service for change fail rate.
- Deployment frequency: production deployments under the deployment rule you choose in Settings, per week.
- Change lead time: the median time from the first commit to production, over changes merged in the period. Where a code host does not link commits, it starts when the change was opened.
- Change fail rate: deployments that were rolled back or hotfixed, over all deployments, shown per service as well.
- Failed deployment recovery time: the median time from a release that needed intervention to the change that fixed it. With an incident source connected, the median time to restore resolved incidents instead, and the tile says which.
- Deployment rework rate: deployments shipped while an incident was open for that service (or, when the incident names no service, for its team), over all deployments. It needs an incident source, and without one it is not measured, never estimated.
Every figure is compared with your own recent past, never an outside grade, and no one is ever named. Changes opened by bots are left out of the change measures. The throughput metrics live on the Speed page, and the instability metrics on the Quality page.
The Speed guide, the Quality guide and the Incidents guide walk through those pages in the app.
Frequently asked questions
What are the four key metrics?
The four key metrics were DORA's original set: lead time for changes, deployment frequency, mean time to recovery and change failure rate. Today DORA uses five: mean time to recovery became failed deployment recovery time, and deployment rework rate was added in 2024.
Is MTTR still a DORA metric?
No. DORA replaced mean time to recovery with failed deployment recovery time, which measures how long it takes to recover from a deployment that failed, rather than from any kind of outage.
Which DORA metric matters most?
None on its own. DORA warns against having "one metric to rule them all". Look at throughput and instability together, then work on whichever constraint is holding the team back most.
Can DORA metrics compare teams?
They should not be used that way. Teams build different software with different risks and users, and DORA advises against disparate comparisons. Compare each team, or better each service, with its own past.
Can DORA metrics measure individual developers?
No. The metrics describe how a whole delivery system behaves: people, code, tools and process together. Using them to rate individuals is misleading and quickly leads to gaming.
How often should we look at them?
Often enough to notice change, not so often that noise looks like news. Many teams glance at them weekly and discuss trends monthly or at retrospectives. Changes in practice take weeks to show up.
What is a good score?
DORA's reports describe how teams in its surveys performed, including the levels known as elite, high, medium and low. They are a reference point, not a target. See DORA performance levels.
Do the metrics work for any kind of software?
Yes. DORA says they can be used for any application or service, regardless of the technology, how complex the deployment is or who the users are (2025 report, page 13).
Learn more
- DORA's software delivery performance metrics, the definitions and pitfalls quoted on this page
- DORA Quick Check
- Accelerate State of DevOps Report 2024
- State of AI-assisted Software Development 2025
- Solidafy guides: What is DORA?, DORA performance levels, Improving software delivery, Glossary