DORA metrics are the software delivery performance measures defined by the DevOps Research and Assessment (DORA) program. The current model has five metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. The first three measure throughput, and the last two measure instability.
You will still see them called the "four keys," because the original model had four metrics. This guide explains how that changed, then defines each metric with a formula, a worked example and the mistakes that most often distort it. All definitions come from DORA's own guide, last updated on 5 January 2026.
What are DORA metrics?
DORA is a research program that studies how teams deliver and operate software. Its delivery metrics answer two questions about one application or service:
- Throughput: how quickly do changes move through the system? Measured by change lead time, deployment frequency and failed deployment recovery time.
- Instability: how well do those deployments go? Measured by change fail rate and deployment rework rate.
DORA says the metrics are "meant to be applied at the application or service level." That matters more than it sounds. A payments API and a marketing site have different risk profiles and release cadences, and DORA warns that blending metrics across teams or whole organisations "can be problematic." Measure each service separately and compare it with its own past.
The metrics are designed to be read together. DORA's guide notes that top performers "do well across all five metrics": speed and stability are not a trade-off.
Four keys or five metrics? Why sources disagree
If you search for DORA metrics, you'll find articles listing four, some listing five, and they don't always agree on what the fifth one is. DORA's history of the metrics explains why.
- The four keys. The classic set was deployment frequency, lead time for changes, change fail rate and time to restore service (also called mean time to recover, or MTTR). Most older articles, and Google's open-source Four Keys project, use this set. That repository was archived in January 2024 and is no longer maintained.
- Reliability was called a "fifth metric" in 2021. DORA added availability as an operational measure in 2018 and broadened it to reliability in 2021. The 2021 report called reliability the fifth metric. DORA has since said that label was a mistake: reliability measures operational performance, not software delivery performance. Articles from that period that list reliability as the fifth DORA metric are out of date.
- 2023: time to restore became failed deployment recovery time. The metric was renamed and narrowed so it only counts failures caused by a change to production, not every outage.
- 2024: deployment rework rate became the actual fifth metric. DORA also regrouped the metrics into throughput and instability.
So "four DORA metrics" describes the original model, and "five DORA metrics" describes the current one. If someone says the fifth metric is reliability, they are working from the 2021 framing. This guide uses the current names. Where people still search for the older names, such as "change failure rate" and "lead time for changes", the headings use those too.
What is deployment frequency?
Definition (DORA): "The number of deployments over a given period or the time between deployments."
Formula:
Deployment frequency = production deployments / time period
or, for services that deploy rarely, the median time between consecutive production deployments.
Worked example. A team's checkout service had 46 production deployments in a 23-working-day month. That is 2 deployments per working day. A second service had 3 deployments that month, roughly one every 10 days, so "time between deployments" is the more readable figure for it.
Frequent deployments keep each change small, which makes it easier to review, test and roll back.
Common measurement mistakes:
- Counting builds or merges instead of production deployments. A build that never reaches users is not a deployment.
- Counting deployments to staging. Only production counts.
- Mixing services. Ten services deploying weekly is not "ten deployments a week" for anyone. Measure per service.
- Celebrating frequency on its own. If frequency rises while change fail rate rises too, you are shipping faster and breaking more.
How do you measure lead time for changes?
DORA now calls this change lead time. Many tools and older articles still use "lead time for changes".
Definition (DORA): "The amount of time it takes for a change to go from committed to version control to deployed in production."
Formula:
Change lead time (per change) = production deploy timestamp − commit timestamp
Reported value = median across all changes deployed in the period
Worked example. Five commits reached production this week with these lead times: 2 hours, 3 hours, 5 hours, 6 hours and 4 days. The median is 5 hours. The mean is about 21 hours, almost entirely because of one change that waited for a manual approval. The median describes the normal path. The outlier tells you where to look.
To find the bottleneck, split the time into stages: review, merge to deploy start, and deploy duration. Long lead times usually come from waiting (review queues, approval gates, flaky tests) rather than slow machines. Monitoring your CI/CD pipeline makes the deploy-side stages visible.
Common measurement mistakes:
- Starting the clock at ticket creation. That measures planning and prioritisation, not the delivery pipeline. DORA's definition starts at the commit.
- Using the merge commit time for every commit in a branch. You lose the time spent in review. Use each commit's timestamp, or the first commit of the change, and be consistent.
- Reporting only the average. One stalled change distorts it. Report the median and an upper percentile, such as p90. Percentiles work the same way here as for latency.
- Excluding changes that were rolled back. They were still deployed, so they belong in the data set.
What is failed deployment recovery time?
Definition (DORA): "The time it takes to recover from a deployment that fails and requires immediate intervention."
This is the metric that used to be called time to restore service or MTTR. The 2023 change narrowed its scope: it only covers failures caused by a deployment. A disk failure or a cloud provider outage still matters for your reliability reporting, and it belongs in your general MTTR, MTBF and MTTF tracking, but it is not part of this DORA metric.
Formula:
Recovery time (per failed deployment) = time service recovered − time of failed deployment
Reported value = median across failed deployments in the period
Worked example. In one quarter, three deployments needed immediate intervention:
| Failed deployment | Deployed | Recovered | Recovery time |
|---|---|---|---|
| Config change broke login | 10:02 | 10:31 | 29 min |
| Migration locked a table | 14:15 | 15:40 | 85 min |
| Bad cache header | 09:00 | 09:12 | 12 min |
The median recovery time is 29 minutes. Notice that the clock starts at the deployment, not when someone noticed. In the second row, the alert fired at 14:50, so 35 of the 85 minutes went by before anyone knew there was a problem. Faster detection shortens this metric directly.
Common measurement mistakes:
- Starting the clock at incident creation. The time between the bad deploy and the first alert is part of the recovery time, and it is often the largest part.
- Stopping the clock at the permanent fix. Recovery means users have working service again, through a rollback, a flag flip or a hotfix. The root-cause fix can come later.
- Including incidents that no deployment caused. That turns the metric back into general MTTR and makes the numbers impossible to compare over time.
- Only reporting the mean. With a handful of failures per quarter, one long outage dominates the average.
If this number is high, the guide to reducing MTTR covers detection, escalation and rollback speed in more depth.
What is change failure rate?
DORA calls this metric change fail rate. "Change failure rate" is the more common search term, and it means the same thing.
Definition (DORA): "The ratio of deployments that require immediate intervention following a deployment."
Formula:
Change fail rate = deployments requiring immediate intervention / total production deployments × 100
Worked example. A service had 120 production deployments in a quarter. Six of them needed immediate intervention: four rollbacks, one hotfix deployed within the hour, and one feature flag turned off because the new code path returned errors. The change fail rate is 6 / 120 × 100 = 5%.
Two more deployments that quarter introduced minor bugs that were found a week later and fixed in the next planned release. Those do not count toward change fail rate, because neither required immediate intervention. (If one of them led to an unplanned fix deployment, that fix counts toward deployment rework rate, covered below.)
What counts as "immediate intervention"?
This is where teams disagree, so write the rule down before you collect data. A reasonable definition counts a deployment as failed if, after it reaches production, the team had to do any of the following:
- roll it back or redeploy the previous version
- ship a hotfix outside the normal release flow
- disable a feature flag to stop user impact
- open an incident and actively respond to it
Feature flag reversals are easy to miss because nothing gets redeployed, but they are still intervention. If you use flags for rollouts, monitor the flag changes themselves so they show up in the data.
How to collect it
The hard part is attribution: linking each rollback, hotfix or incident to the deployment that caused it. The usual approach is:
- Record every production deployment with an ID, service and timestamp.
- When an incident opens, record which deployment it is attributed to. Your post-mortem template should include this field.
- Tag rollbacks and hotfix deployments with the deployment they reverse.
- Count distinct failed deployments, not incidents. One bad deploy that triggers three alerts is one failure.
Common measurement mistakes
- Counting incidents instead of deployments. The numerator is failed deployments.
- Counting every bug ever traced to a deployment. That makes the metric depend on how long you look. The definition covers immediate intervention only.
- Quietly excluding flag rollbacks or "small" reverts. This makes the number look better without anything improving.
- Relabelling to hit a target. If change fail rate becomes a goal, people learn to call rollbacks "planned". Review borderline cases in a consistent way and keep the metric out of performance reviews.
- Missing failures that return
200 OK. A deploy that serves an empty page or a broken checkout with a success status code will not trigger a status-code check. Response body validation catches those, so they get counted.
Rollout strategies such as canary and blue-green deployments do not change the definition, but they tend to reduce how many users a failure reaches and how long recovery takes.
What is deployment rework rate?
Definition (DORA): "The ratio of deployments that are unplanned but happen as a result of an incident in production."
Formula:
Deployment rework rate = unplanned deployments caused by a production incident / total production deployments × 100
Worked example. Using the same quarter of 120 deployments: 9 of them were unplanned deployments shipped to fix a problem in production. Six of those were the hotfixes and redeploys from the failed changes above, and three fixed bugs discovered days after the original release. The deployment rework rate is 9 / 120 × 100 = 7.5%.
This fills a gap in change fail rate: a change can pass its first hour cleanly and still cause cleanup work days later. DORA's history page describes it as a proxy for rework, meaning time spent fixing shipped work instead of building new work.
Common measurement mistakes:
- Counting planned follow-up work. A scheduled second phase of a feature is not rework. Only unplanned deployments driven by a production incident count.
- Tagging the wrong deployment. The corrective deployment is the one counted as rework, not the original change.
- No way to mark a deploy as unplanned. If your pipeline does not record why a deploy happened, add a label or a commit convention, for example a
hotfixtag tied to an incident ID.
How the five metrics work together
Each metric is easy to improve on its own in ways that make delivery worse. Reading them in pairs prevents that:
| If you push on... | ...without watching... | You risk |
|---|---|---|
| Deployment frequency | Change fail rate | Shipping faster and breaking more |
| Change lead time | Change fail rate | Skipping review and testing to save time |
| Change fail rate | Deployment frequency | Slow, fearful releases that batch up risk |
| Change fail rate | Deployment rework rate | Fewer immediate failures, more delayed cleanup |
| Throughput overall | Failed deployment recovery time | Speed with no ability to recover |
DORA's guide lists similar pitfalls: using the metrics as targets (which invites gaming, per Goodhart's law), relying on a single metric, comparing very different applications, and turning the metrics into a competition between teams. The useful question is whether throughput improves for a service without instability getting worse.
You may also see "elite, high, medium, low" performance tiers quoted with specific thresholds. Those benchmarks come from particular annual reports and change between research periods, so a threshold copied from an old article may no longer apply. DORA's Quick Check is the current place to compare a service against DORA's data.
Where monitoring data fits
Three of the five metrics depend on knowing when production broke and when it recovered, and that data comes from monitoring and incident tooling rather than from version control.
- Failed deployment recovery time starts at the bad deployment. An outside-in uptime check running every minute narrows the gap between deploy and detection, which is often the biggest part of the recovery time.
- Change fail rate needs evidence that a deployment caused user impact. Timestamps from monitoring alerts, matched against deploy timestamps, give you that link.
- Deployment rework rate needs incidents to point to. If problems are only discovered through customer emails, some will never get an incident record and the rework will not be counted.
How to start tracking DORA metrics
You don't need a dedicated platform. Pick one service, log every production deployment (service, commit SHA, timestamp, planned or not), make "caused by deployment" a required field on incidents, and write down what counts as immediate intervention and as recovered. A monthly spreadsheet is enough to start. DORA's guide itself warns against over-investing in measurement before improving anything.
FAQ
What are the five DORA metrics?
Change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. The first three measure throughput and the last two measure instability.
What are the four DORA metrics?
The original "four keys" were deployment frequency, lead time for changes, change fail rate and time to restore service. DORA has since renamed time to restore service to failed deployment recovery time (2023) and added deployment rework rate (2024).
Is reliability the fifth DORA metric?
Not any more. The 2021 report called reliability the fifth metric, but DORA later said that was incorrect, because reliability measures operational performance rather than software delivery. The current fifth metric is deployment rework rate.
How is change failure rate calculated?
Divide the number of production deployments that required immediate intervention (rollback, hotfix, flag reversal or incident response) by the total number of production deployments, then multiply by 100.
What is the difference between DORA lead time and cycle time?
DORA's change lead time runs from commit to production deployment. Cycle time is used more loosely and often starts earlier, for example when work begins on a ticket. If you report both, label them clearly so they are not confused.
Summary
DORA metrics measure software delivery for one service at a time. The current model has five: change lead time, deployment frequency and failed deployment recovery time for throughput, and change fail rate and deployment rework rate for instability. The "four keys" are the earlier version of the same idea.
Define each event precisely, link deployments to the incidents and fixes they cause, report medians rather than averages, and track your own trend instead of chasing a benchmark label.