DORA Metrics: What They Are and How to Measure Them

DORA metrics are the software delivery performance measures defined by DORA (DevOps Research and Assessment), and DORA's current model has five of them: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. They show how quickly a team moves changes into production and how well those deployments go.

If you learned DORA metrics as "the four keys," you are not wrong, just a version behind. DORA's research started with four metrics, renamed one of them in 2023, and added a fifth in 2024. This guide uses DORA's own current definitions from its guide, DORA's software delivery performance metrics, and its history of DORA's software delivery metrics. DORA is a program run by Google Cloud.

TL;DR: DORA metrics

• Five metrics, two factors. Throughput: change lead time, deployment frequency, failed deployment recovery time. Instability: change fail rate, deployment rework rate.
• The four keys are the older model. Deployment frequency, lead time, MTTR and change fail rate. MTTR became failed deployment recovery time in 2023, and deployment rework rate was added in 2024.
• Speed and stability are not a trade-off. DORA's research finds the metrics are correlated for most teams.
• Measure one application or service at a time. Blending across very different teams or systems is misleading.
• Do not turn them into targets. DORA lists "setting metrics as a goal" as its first common pitfall.

What are DORA metrics?

DORA metrics are a small set of outcome measures for the software delivery process, chosen because DORA's research shows they predict better organizational performance and team well-being. They describe the delivery system, not individual people and not the product's business results.

DORA groups the metrics into two factors:

• Throughput is how many changes can move through the system over a period of time. Higher throughput means the system can move more changes to production.
• Instability is how well deployments go. When deployments go well, teams can push more changes with confidence and users are less likely to hit problems right after a deploy.

DORA describes these metrics as leading indicators for organizational performance and employee well-being, and lagging indicators for software development and delivery practices. In practice that means they tell you how your delivery system is doing; the practices that move them (smaller changes, test automation, faster review) are what you actually work on.

What are the five DORA metrics?

The five DORA metrics are change lead time, deployment frequency and failed deployment recovery time (throughput), plus change fail rate and deployment rework rate (instability). The definitions below follow DORA's guide.

1. Change lead time

Change lead time is the amount of time it takes for a change to go from committed to version control to deployed in production. It captures everything between the commit and the deploy: waiting for review, review itself, CI, staging and the release step.

Lead time is where process friction shows up. A team that writes code quickly but waits days for review has a long change lead time, and so does a team with fast review and a manual weekly release.

2. Deployment frequency

Deployment frequency is the number of deployments over a given period, or the time between deployments. It is the most visible signal of throughput.

What counts as a deployment depends on your architecture: a full release for a monolith, or a deploy of any single service in a service-oriented system. Pick a definition and count consistently.

3. Failed deployment recovery time

Failed deployment recovery time is the time it takes to recover from a deployment that fails and requires immediate intervention. It replaced mean time to recover (MTTR), also called time to restore service, in 2023.

The reason for the change matters for how you measure it. DORA's history explains that the older definitions did not separate failures caused by a software change from failures caused by external events, such as a data center outage. Failed deployment recovery time counts only recovery from an impairment that a change to production caused.

4. Change fail rate

Change fail rate is the ratio of deployments that require immediate intervention following a deployment. DORA notes this likely means a rollback of the change or a hotfix to remediate issues quickly.

Define "failure" honestly. A deploy that degraded service and was patched with a quick follow-up still counted as a failed change.

5. Deployment rework rate

Deployment rework rate is the ratio of deployments that are unplanned but happen as a result of an incident in production. It is the newest DORA metric, introduced in 2024.

DORA's history explains the origin: researchers found that change fail rate acted as a proxy for the amount of rework a team had to do, and added deployment rework rate to measure that rework directly. If a large share of your deploys are unplanned fixes, the team is spending delivery capacity on repair rather than on new work.

What are the 4 DORA metrics, and what changed?

The original four DORA metrics, often called the four keys, were deployment frequency, lead time for changes, mean time to recover (MTTR), and change fail rate. Most older articles and dashboards still use this set.

DORA's history page traces how the model evolved:

Period	What DORA measured
2014	Started with deployment frequency, lead time for changes, MTTR and change fail rate. In that first study change fail rate did not fit the statistical construct, so IT performance was defined using the other three.
2015	Settled into throughput (deployment frequency, lead time) and stability (MTTR, change fail rate).
2018	Added availability as a measure of operational performance, alongside the four delivery metrics.
2021	Broadened availability into reliability, which DORA now describes as an operational measure rather than a fifth delivery metric.
2023	Renamed and redefined MTTR as failed deployment recovery time.
2024	Added deployment rework rate, moving to five metrics grouped as throughput and instability.

If your tooling still reports MTTR across all incidents, it is measuring something broader than DORA's current recovery metric. That is not wrong for operations, but it is not the DORA definition.

How do you measure DORA metrics?

Measure DORA metrics per application or service, from the systems that already record commits, deployments and incidents, and track them over time rather than as a single snapshot. DORA's guide also suggests starting with its Quick Check to set a baseline before building integrations.

Where each metric's data usually comes from:

• Change lead time joins your version control system (when the change was committed) with your deployment system (when it reached production). The join is the hard part, because the data lives in two places.
• Deployment frequency comes from your CI/CD or deployment tooling. Count production deploy events with the definition you chose.
• Change fail rate needs a link between deployments and the interventions that followed them: rollbacks, hotfixes, or incidents tied to a specific deploy.
• Failed deployment recovery time runs from the failure caused by a deployment to recovery. Your incident tooling usually holds the timestamps, but only change-caused incidents belong in it.
• Deployment rework rate needs each deploy labeled as planned or as an unplanned fix for a production incident. Many teams tag hotfix releases for this.

DORA is explicit that you do not need a large measurement project to start. Its pitfalls list warns against "focusing on measurement at the expense of improvement," and suggests that conversations, the Quick Check, or a product with pre-built integrations may be a better first step than building integrations to every system.

Common DORA metrics measurement mistakes

• Counting only big releases. Inconsistent deploy definitions make deployment frequency meaningless across periods.
• Leaving review wait out of lead time. Change lead time starts at commit. Time a pull request spends waiting for review is part of it.
• Under-reporting failures. If quick follow-up fixes are not counted, change fail rate and rework rate look better than reality.
• Mixing external outages into recovery time. DORA's current recovery metric covers deployment-caused failures only.
• Blending very different systems. DORA advises applying the metrics to one application or service at a time, because context differs.

How do teams improve DORA metrics?

DORA's guide names reducing batch size as a common way to improve all five DORA metrics: smaller changes are easier to reason about, move through delivery faster, and are easier to recover from. Working this way improves throughput and stability together.

DORA's suggested process is to gather the cross-functional team that builds, delivers and operates the application, set a baseline with the Quick Check, and talk through the friction points in the delivery process. From there, DORA's broader research links many technical and cultural capabilities to delivery performance; its capability catalog covers them.

Code review is one of the places batch size and lead time meet. Large pull requests wait longer for review and are harder to review well, which is why the guide on how to reduce PR cycle time with AI code review and the explainer on PR cycle time pair naturally with DORA's lead time metric. If routine pull requests sit in the same queue as risky ones, speeding up pull request approvals safely covers risk-based routing.

Why do DORA metrics matter for engineering teams?

DORA metrics matter because they replace opinions about delivery with a small set of measured outcomes, and DORA's research shows speed and stability move together. DORA reports that top performers do well across all five metrics and low performers do poorly.

That finding is the practical point. Teams often assume they must slow down to be safe. DORA's data says the metrics are correlated for most teams, so the work that makes delivery faster (small batches, automated testing, quick feedback) is usually the same work that makes it safer.

DORA metrics also give engineering leaders a shared language. Throughput answers "how fast can we get a change to users?" Instability answers "how often does that go wrong, and how much rework does it cost?" Both questions make sense outside engineering.

How does Macroscope relate to DORA metrics?

Macroscope does not compute DORA metrics; its Status product explains what changed in the codebase and where engineering effort is going, which is useful context next to a DORA dashboard. DORA metrics tell you that lead time or rework rate moved. They do not tell you which work drove it.

Macroscope Status processes every commit and produces:

• Commit summaries: a searchable, chronological feed with a plain-language summary of each commit, estimated coding effort, and optional Jira or Linear context.
• Areas: work grouped by product or roadmap area, with executive summaries updated several times a day and weekly digests.
• Productivity insights: dashboards and weekly email reports with coding-time estimates and trends.

Status is billed at $0.05 per processed commit, with no per-seat fees, and every new workspace gets $100 in usage credit. Separately, Macroscope's AI code review runs on pull requests, which is part of the window change lead time measures. For a broader view of measuring engineering work, see how to measure developer productivity.

What are the limitations of DORA metrics?

DORA metrics measure software delivery outcomes, so they leave out developer experience, code quality and business impact by design. Pair them with other measures rather than stretching them.

• Developer experience. A team can post strong numbers while burning out. Pair DORA metrics with direct conversations or surveys about workload.
• Code quality. Delivery metrics do not measure maintainability or technical debt.
• Business impact. Shipping often does not mean shipping the right things. Product metrics fill that gap.
• Individual performance. DORA metrics describe a delivery system. Using them to rank individuals misreads them. DORA also warns against siloed ownership and against competing with other teams, and recommends sharing all five metrics across development, operations and release teams.

Frequently Asked Questions

What are the 4 DORA metrics?

The original four DORA metrics, or four keys, are deployment frequency, lead time for changes, mean time to recover (MTTR), and change fail rate. DORA has since renamed MTTR to failed deployment recovery time (2023) and added deployment rework rate (2024), so its current model has five metrics.

What are the 5 DORA metrics?

DORA's current five metrics are 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.

How do you measure DORA metrics?

Measure them per application or service. Change lead time joins commit timestamps with production deploy timestamps. Deployment frequency comes from deploy events. Change fail rate and deployment rework rate need each deployment linked to any rollback, hotfix, or incident that followed. Failed deployment recovery time runs from a deployment-caused failure to recovery. DORA suggests starting with its Quick Check to set a baseline.

What replaced MTTR in DORA metrics?

Failed deployment recovery time replaced mean time to recover in 2023. DORA changed it because the older definition did not distinguish failures caused by a software change from failures caused by external events. The new metric counts only recovery from deployment-caused failures.

What is deployment rework rate?

Deployment rework rate is the ratio of deployments that are unplanned but happen as a result of an incident in production. DORA added it in 2024 after finding that change fail rate was acting as a proxy for how much rework a team does.

How often should we measure DORA metrics?

Collect data continuously and review trends on a regular cadence, such as monthly or quarterly. DORA emphasizes measuring over time to see how performance is changing, and single-day swings are usually noise from release schedules or one-off incidents.

Should we set targets for DORA metrics?

DORA advises against treating the metrics as goals. Its guide lists setting metrics as a goal as a common pitfall, because broad mandates invite teams to game the numbers. Use them to find friction and track improvement over time.

Can small teams benefit from DORA metrics?

Yes. DORA says the metrics work for any type of technology and are best applied one application or service at a time, which fits small teams well. Focus on your own trend rather than comparing against other organizations.

What is the relationship between DORA metrics and SPACE?

SPACE is a broader developer productivity framework covering satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. DORA metrics are specific delivery outcomes. The two are complementary: DORA tells you how the delivery system performs, and SPACE adds dimensions such as developer satisfaction that DORA does not measure.

How do DORA metrics apply to platform and infrastructure teams?

Apply them to the service the platform team delivers. Deployment frequency becomes how often platform changes ship, and change fail rate, recovery time and rework rate apply directly, since platform failures affect every team downstream.

Does Macroscope calculate DORA metrics?

No. Macroscope Status summarizes every commit, groups work into areas, and reports coding-time trends, which helps explain what changed when a DORA metric moves. It is not a DORA metrics calculator.