The DORA Metrics: What They Measures & What Leaders Need to Know

Imagine a world where you could quantify the exact heartbeat of your engineering organization with the precision of a Swiss watch. What if we told you that you can actually do this through a handy, research-backed measurement standard called DORA metrics?

For years, leaders have been flying blind, buried under a mountain of vanity metrics and gut feelings about their team’s productivity. This is where DORA metrics change the game. This measurement standard shifts the conversation from “how busy are we?” to “how much value are we actually delivering?”

You might be wondering, “what are DORA metrics and how can they help level up my business?”

Don’t worry, in this guide we’re going to show you the ins-and-outs of this small yet mighty set of metrics that connect software delivery to real outcomes. Ready to dive in head-first?

Brief History of DORA Metrics

DORA metrics come from the research and began with the annual State of DevOps reports, starting in 2013. This research collected insights and analyzed thousands of engineering teams across industries. The goal was not to promote a specific tool or framework, but to identify which outcomes consistently separate elite teams from struggling organizations.

What the research revealed contradicted a widely held assumption. Faster delivery was not, as many believed, inherently riskier. The highest-performing teams excelled at both moving work through the system quickly and avoiding the kinds of changes that introduced instability. The data showed you could have both SPEED and STABILITY (by avoiding instability), with the right measurements.

They delivered software faster, deployed more frequently, and still maintained low failure rates and fast restore service times.

The findings of the State of DevOps reports were codified in the 2018 book Accelerate, which introduced what became known as the DORA metrics and established them as a research-backed measurement standard for measuring the performance of teams ability to deliver software.

Who Founded the DORA Metrics?

DORA is the result of years of research that result of over seven years of intensive data collection led by Dr. Nicole Forsgren, Jez Humble, and Gene Kim. They were the ones to identify the “secret sauce” of high-performing teams, which led to the creation of this modern measurement standard.

Their findings were eventually published in the seminal book Accelerate and continue to live on through the annual State of DevOps Report, now backed by Google Cloud.

Now, let’s sink our teeth into the actual meat of what DORA metrics are.

What Are DORA Metrics?

DORA metrics are five key metrics that assess how effectively teams deliver software. Together they form research-backed standards that measure software delivery performance through two lenses: throughput and instability.

For the organization, these two lenses translate directly into key factors that affect its ability to deliver value to customers.

• Throughput answers: Are we moving fast enough to stay competitive and respond to what the market needs?
• Instability answers: Are we shipping with enough reliability that we’re building customer trust rather than eroding it?

The five DORA metrics address the questions of Throughput and Instability at the team level.

Throughput Measures

• Change lead time: The amount of time it takes for a change to go from committed to version control to deployed in production.
• Deployment frequency: The number of deployments over a given period or the time between deployments.
• Failed deployment recovery time: * The time it takes to recover from a deployment that fails and requires immediate intervention.

Instability Measures

• Change fail rate: The ratio of deployments that require immediate intervention following a deployment. Likely resulting in a rollback of the changes or a “hotfix” to quickly remediate any issues.
• Deployment rework rate: The ratio of deployments that are unplanned but happen as a result of an incident in production.

*Recovery speed is a throughput measure because how quickly a team can resolve a failed deployment directly affects its ability to keep delivering.

DORA metrics provide system-level insight, which makes them applicable across software development contexts, whether teams ship daily or monthly, and whether they operate monoliths or microservices.

Why the 5 DORA Metrics Became the Industry Standard

The research behind the DORA metrics connects software delivery performance directly to outcomes that appear on every leadership agenda.

Organizations whose teams score in the top delivery performance tier are roughly twice as likely to meet or exceed their organizational goals. That relationship holds across profitability, market share, customer growth, and operational efficiency. It holds in commercial and non-commercial organizations. It holds across industries, company sizes, and geographies.

The DORA metrics allow organizations to answer key value questions such as “How fast?”, “Do we have good quality?”, and “Will our customers be happy?” How reliably your organization delivers software is not a technology concern that lives inside the engineering organization. It is a measurable predictor of whether your organization hits its goals. And with software an integral part of nearly all industries today, DORA allows an organization to directly connect that work to the bottom line of any product or service.

What the DORA Metrics Reveal About Your Business

DORA metrics are most valuable when leaders interpret them as answers to business questions rather than as abstract numbers.

1. Change Lead Time

Change Lead Time measures the delay between when work is committed to be built and customer impact. This matters to leaders because the bottleneck is rarely where they expect it. Development time frequently accounts for less than 20% of the total lead time, with the largest delays occurring before a developer ever starts work.

Long lead time often points to delays as a result of bottlenecks such as:

• Phase gates and formal governance checkpoints
• Handoffs between teams or organizations
• Inline approval steps in the build or release process
• Rework cycles that return completed work to an earlier stage
• Defects discovered late that require re-review or re-approval
• Unclear requirements that generate back-and-forth before work can begin
• Testing gaps that require human intervention
• Complex deployment processes

Tracking lead time helps organizations identify bottlenecks and improve flow. Deployment frequency, change lead time, and deployment rework rate reveal whether improvements are sustainable.

2. Deployment Frequency Measures Delivery Flow

Deployment frequency measures how often a development team deploys code to production. Higher deployment frequency indicates smaller batch sizes, faster feedback, and more frequent learning.

Organizations with higher deployment frequency can experiment more safely and deliver software faster. Frequent deployments also reduce the risk associated with each individual change.

3. Failed Deployment Recovery Time Measures Resilience

Failed deployment recovery time measures how quickly a team can recover from a deployment that fails. While we instinctively think of failed deployments as a quality or stability issue, it is more accurately a throughput measure. How fast a team recovers from a failed deployment directly determines how quickly it can get back to delivering. A team that takes days to recover is not just managing an incident; it is generating waste and not creating value.

Organizations with faster recovery times maintain delivery momentum even when things go wrong. Recovery speed is not purely an engineering problem. It reflects organizational decisions about investment in deployment infrastructure, incident response practices, and cross-team coordination. Every hour a deployment failure goes unresolved is an hour of lost customer trust, delayed value, and compounding risk to the business.

4. Change Fail Rate Reflects Software Quality

If Change Fail Rate is the accident rate on the highway, Failed Deployment Recovery Time is how fast emergency responders clear the road and restore normal flow. The faster the road clears, the sooner everyone gets moving again.

Change Fail Rate measures the proportion of deployments that require immediate intervention, whether through a rollback, a hotfix, or an incident response. It is the instability signal that tells leaders how reliably the delivery system is producing outcomes worth keeping.

Why It’s Your Early Warning System

A high failure rate is rarely a matter of bad luck. It’s a flashing red light signaling deeper issues in your delivery pipeline, such as:

• Requirements that were unclear or incomplete before development began
• Code or configuration changes that introduced unintended behavior
• Environment or infrastructure inconsistencies between testing and production
• Release sequencing failures in complex or dependent systems

Reducing your Change Fail Rate accelerates the ability to deliver… When the failure rate drops, the constant “firefighting” ends. This lowers the operational burden on the entire organization, allowing it to focus on innovation instead of damage control.

5. Deployment Rework Rate Signals Upstream Quality Problems

Imagine a newly opened bridge. It passed all the inspections and looks great. Only corners were cut, or something was missed, and the result is that the bridge collapses. Now, the road is closed while the bridge is repaired. This is Deployment Rework Rate.

It measures how many unplanned deployments occur to fix escaped defects found in production. The deployment succeeded. The quality did not.

A high Deployment Rework Rate is not a signal to improve incident response. It is a flashing red warning signal to look upstream. Look at the clarity of your requirements, the depth of refinement and design, the depth of test coverage, and the shared definition of done. Unplanned deployment is the cost. The escaped defect is the problem.

How to Measure DORA Metrics Reliably

Measuring DORA metrics effectively requires consistent definitions and trustworthy data sources. The goal is not perfect precision, but reliable trends. Let’s break it down.

Establish Shared Definitions Amongst Teams

Before touching a dashboard, engineering leaders must align on the rules of the road. If Team A defines a failure as a total outage but Team B includes minor UI bugs, your data is useless. You must reach a consensus on exactly what constitutes a production deployment, a failure, and a completed restoration. A shared Definition of Done will go a long way to creating the common understanding all teams need.

Collect Data from Systems of Record

You don’t need new tools, just connect the ones you already have. Most organizations already have the data they need to create DORA-level metrics.

• Change Lead Time: version control systems, project management tools
• Deployment Frequency: CI/CD pipelines
• Failed Deployment Recovery Time: incident management tools, deployment logs
• Change Fail Rate: deployment logs, incident management tools
• Deployment Rework Rate: incident management tools, deployment logs, production monitoring

As Google Cloud has highlighted through ongoing DevOps research and assessment work, automation is increasingly important for consistent data collection.

Metric-by-Metric Guidance

Take these five calculations into account:

• Change Lead Time: Measure the time from when work is formally committed to the plan until it reaches production. This includes all time across the system, not just development time.
• Deployment Frequency: Count successful deployments to production over a consistent time window. Use the same window every measurement period to ensure comparable trends.
• Failed Deployment Recovery Time: Measure the time from when a deployment failure is detected until the system is restored and delivery can resume.
• Change Fail Rate: Divide the number of deployments requiring immediate intervention by the total number of deployments in the same period.
• Deployment Rework Rate: Divide the number of unplanned deployments triggered by a production incident by the total number of deployments in the same period. These must be tagged at the time of deployment to be measured accurately.

Pro-Tip: Don’t obsess over a single bad week. Focus on the trend lines to see if your process is maturing or decaying over time.

How to Use DORA Metrics to Align Goals and Drive Improvement

DORA metrics become powerful when embedded with broader goals in a total system. They help teams balance throughput and minimize instability instead of optimizing one at the expense of the other.

When organizations connect DORA metrics to outcome-focused planning, delivery conversations become more objective. Teams can justify investments in automated testing, deployment processes, or incident response using data rather than opinion.

We often see strong results when DORA metrics are integrated into a KPI’s and a structured framework such as Objectives and Key Results.

Building Trust Around Measurement

The most common mistake leaders make is turning these metrics into mandates. When a measure becomes a target, teams optimize for the number rather than the outcome. This is Goodhart’s Law, and it applies directly here.

To use DORA metrics effectively:

• Avoid mandates. “Every team must deploy daily by year end” produces daily deployments, not better delivery performance.
• Avoid cross-team comparisons. These metrics apply within the context of a single application or service. Comparing a mobile app to a core banking system tells you nothing useful.
• Use all five together. Optimizing one metric in isolation drives wrong behaviors. A team chasing Deployment Frequency without watching Change Fail Rate will ship faster and break more.
• Share visibility across the whole delivery system. When development, operations, and release teams each see only their slice, the system-level diagnostic value disappears.

Coaching plays a key role here. Organizations that invest in coaching capability, as discussed in our article on measuring Agile coach performance, tend to sustain improvements more effectively.

Role-Based Use of DORA Metrics: A Universal Language

When every level of the organization looks at the same scoreboard, alignment becomes possible, allowing the organization to focus on strategic goals rather than managing day-to-day friction.

Here is how different levels of the organization leverage the DORA metrics to drive success:

• Business Leaders use DORA metrics as organizational performance indicators. Are we delivering value to customers fast enough to stay competitive? Is our delivery reliable enough to protect customer trust? Are we improving over time, or are we stagnating? The DORA benchmarking tiers, Elite, High, Medium, and Low, give leaders an honest picture of where the organization stands in comparison to the industry as a whole. Instead of subjective measures, they have valuable benchmarks for improving the system.
• Technology Leaders use DORA metrics as system diagnostics. They look across all five metrics to identify where the delivery system is constrained, justify investment decisions in tooling, infrastructure, and capability development. The metrics also allow them to track whether improvement efforts are producing measurable change over time.
• Development Teams use DORA metrics as a feedback loop. Change Lead Time and Deployment Frequency reveal where work is slowing down before it reaches production. Change Fail Rate and Deployment Rework Rate signal where quality is escaping the process. Failed Deployment Recovery Time reflects how quickly the team responds to failures found in production. Together, the five metrics give teams the data to examine their technical debt, testing coverage, process improvement, and their own accountability for the work they create.
• Platform Teams use DORA metrics to measure the health of the systems on which the product runs. Deployment Frequency and Failed Deployment Recovery Time reflect whether the pipeline and production environment are supporting or constraining the teams building in them.

Turn DORA Metrics into Sustainable Advantage

Understanding what DORA metrics are is only the starting point. The real value comes from using them to guide decisions, improve delivery performance, and strengthen customer trust.

When organizations measure consistently, discuss results openly, and focus on system improvement, DORA metrics become a strategic asset rather than a reporting exercise.

If you want support implementing DORA metrics in a way that aligns delivery, leadership, and outcomes, Hyperdrive can help. If you are ready to level up your business, get in touch with our expert coaches today!

Frequently Asked Questions

1. Should I use DORA metrics to evaluate individual developer performance?

No. This is a red flag and is one of the most common and most damaging misuses of DORA metrics. DORA metrics are designed to measure the system and the process, not the person. If you use Deployment Frequency to rank individuals, you’ll likely encourage micro-commits (small, meaningless changes just to boost numbers) rather than actual value. Use DORA to find bottlenecks in your pipeline, not to discipline engineers.

2. How do I measure Lead Time for a monolith vs. microservices?

In a microservices architecture, Change Lead Time is usually straightforward per service. For a monolith, it can be trickier because code might sit in a queue waiting for a massive coordinated release. In these cases, it’s best to measure the Change Lead Time to Production (tracking from the moment code is committed to be built until it is live) even if that includes a long wait for a release to production.

3. What is a good Change Failure Rate?

According to the State of DevOps research, elite teams maintain a Change Fail Rate of 5%. However, the ideal number depends on your industry. Focus on improving your own baseline rather than chasing a universal perfect number.

4. Can I automate DORA tracking if we still have manual QA steps?

Yes, but your Change Lead Time will reflect that manual delay. Many teams start by manually tagging data in Jira or spreadsheets to get a baseline. As you mature, you should aim to automate the data collection by linking your CI/CD pipeline (like GitHub Actions or GitLab) directly to your incident management tool (like PagerDuty).

5. How do DORA metrics differ from Flow Metrics?

While they overlap, they serve different purposes. DORA focuses on the delivery pipeline’s health (Throughput and Instability). Flow Metrics (from the Value Stream Management world) focus on how work moves through the entire system, including the ideation phase before a developer even starts coding. Most high-delivering organizations use DORA as their foundation and add Flow Metrics once their delivery pipeline is stable.