What Is DORA Metrics?

DORA metrics are four measures of software delivery performance, deployment frequency, lead time for changes, change failure rate, and time to restore service, developed by the DevOps Research and Assessment team to give engineering organizations a consistent, evidence-based way to gauge how well they build and ship software. The metrics look at both speed, how often and how fast teams ship changes, and stability, how often those changes break something and how quickly the team recovers. Together, they give a more honest picture of delivery performance than looking at either speed or stability alone, since a team that ships fast but breaks production constantly isn't actually performing well, and neither is a team that's stable because it barely ships anything.

The reason DORA metrics definition matters is that engineering leaders have long struggled to answer a basic question with any rigor: is our software delivery actually good, and how do we know? Lines of code, story points, and hours worked never answered that question honestly, because they measure activity, not outcomes, and they're trivially easy to game. The research behind DORA, which started as an annual State of DevOps survey and grew into a multi-year study across thousands of organizations, set out to find metrics that actually correlated with organizational performance, meaning profitability, market share, and customer satisfaction, not just an engineering team's sense of busyness. The four metrics that emerged are the ones that held up across that research as reliable predictors of high-performing software organizations.

What distinguishes DORA metrics from other engineering measurement approaches is that they measure the software delivery pipeline as a system, from code committed to running safely in production, rather than measuring any one team or any one stage in isolation. Deployment frequency and lead time for changes capture throughput, essentially how fast value moves from an idea to something a customer can use. Change failure rate and time to restore service capture stability, essentially how much that speed costs you in broken releases and how well you recover when things go wrong. A team looking at only the throughput metrics might look fast while quietly accumulating operational risk, and a team looking at only the stability metrics might look safe while actually being far too slow to be competitive.

By 2026, DORA metrics have become close to a industry-standard vocabulary for talking about delivery performance, showing up in engineering dashboards, platform engineering tooling, and performance conversations across companies of very different sizes and industries. The four categories, from Elite to Low, that the DORA research uses to bucket organizations based on their metrics have become a common reference point even outside the original research context. At the same time, there's a growing, healthy pushback against treating the four numbers as a scorecard to hit rather than a diagnostic tool, because teams that optimize the numbers directly rather than the underlying delivery practice tend to produce metrics that look great and outcomes that don't.

This page covers what each of the four DORA metrics actually measures and how it's calculated, why these specific four measures were chosen over the many other things you could track, how the performance categories work and what they mean in practice, where DORA metrics genuinely help a team and where they get misused, and how a team introduces them without triggering the gaming and anxiety that comes from turning a diagnostic into a scorecard. The durable idea underneath the framework is that speed and stability need to be measured together, because either one without the other gives you a false picture of how well your organization actually delivers software.

• DORA metrics are four measures, deployment frequency, lead time for changes, change failure rate, and time to restore service, that together capture both speed and stability of software delivery.
• They came out of multi-year research designed to find measures that actually correlate with organizational performance, not just engineering activity.
• The metrics work as a system: throughput measures alone can hide operational risk, and stability measures alone can hide a team that's too slow to be competitive.
• By 2026, DORA has become a common shared vocabulary for delivery performance, complete with Elite, High, Medium, and Low performance categories.
• The framework is meant as a diagnostic tool for improving how a team works, not a scorecard to hit, and treating it as the latter tends to produce gamed numbers and worse real outcomes.

Deployment frequency measures how often an organization successfully releases to production. This isn't about counting commits or pull requests; it's specifically about code reaching production and being available to users. Elite performers in the DORA research tend to deploy on demand, multiple times a day, while lower-performing organizations might deploy once a month or less. The metric matters because deployment frequency is a rough proxy for batch size: teams that deploy rarely tend to bundle large amounts of change into each release, which makes each release riskier and harder to debug when something goes wrong, while teams that deploy often tend to ship small, contained changes that are easier to reason about and easier to roll back.

Lead time for changes measures the time from a code commit being made to that code running successfully in production. It captures the entire path a change takes through code review, testing, staging, and deployment, and it's one of the clearest signals of how much friction exists in an organization's delivery pipeline. A short lead time doesn't just mean things ship fast, it means the whole path from an engineer's local change to a working feature is well-oiled: automated tests that don't require manual babysitting, a deployment process that doesn't need a person to click through a dozen manual steps, and a review process that doesn't get stuck waiting days for someone's attention.

Change failure rate measures the percentage of deployments that cause a failure in production, meaning something that requires a hotfix, rollback, or immediate follow-up fix. This is the metric that keeps deployment frequency and lead time honest. It would be trivial to look fast on the first two metrics by skipping tests and pushing changes without much scrutiny, but that approach shows up immediately as a high change failure rate, which tells you the speed is coming at the cost of quality rather than from genuinely efficient practices.

Time to restore service, sometimes called mean time to recovery, measures how long it takes an organization to restore service after a production failure. This isn't just about how fast an individual engineer can push a fix; it reflects the maturity of an organization's incident response, monitoring, alerting, and rollback capabilities. A team with excellent monitoring that catches problems within minutes and a well-practiced rollback process will restore service far faster than a team that finds out about an outage from a customer complaint and then has to manually diagnose what went wrong before it can even start fixing it.

Each of these four numbers is usually calculated over a rolling window, often the trailing four weeks or a quarter, rather than as a single snapshot, because software delivery is naturally lumpy. A team might deploy fifteen times one week and twice the next because of a holiday or an unusually complex piece of work, and looking at a single week in isolation would give a misleading picture. Rolling averages smooth out that natural variance and make it easier to spot a genuine trend, an improving or degrading pattern over months, rather than reacting to noise from any single unusual week.

The DORA metrics originated from research led by Nicole Forsgren, Jez Humble, and Gene Kim, published most visibly in the book "Accelerate" and in the annual State of DevOps reports that ran for years surveying thousands of engineering professionals across industries. The research team's core question was ambitious: could you identify a small set of measurable practices and outcomes that reliably distinguished high-performing software organizations from low-performing ones, using rigorous statistical methods rather than anecdote or intuition.

What made the research credible, and what's kept it relevant for years afterward, is that it didn't start from a theory about what good delivery should look like and then look for data to confirm it. It started from broad survey data across a wide range of organizational sizes, industries, and maturity levels, and used statistical analysis to find which practices and outcomes actually correlated with business results like profitability and market share, not just with each other. The four metrics that emerged, deployment frequency, lead time, change failure rate, and time to restore, were the ones that held up as reliable predictors across that analysis, which is why they earned the specific status they have rather than just being one reasonable list among many possible ones.

The research continued to evolve after the initial findings, eventually adding a fifth measure in some later analyses, often described as reliability or operational performance, reflecting how well a system meets user expectations for availability and performance over time. Most conversations about "DORA metrics" still default to the original four, though, because those are the ones with the longest track record and the widest adoption in tooling and industry conversation.

It's worth understanding this history because it explains why DORA metrics carry more weight than an arbitrary engineering KPI a manager invented. They're not a made-up scorecard; they're the output of an attempt to answer, with actual data, a question engineering leadership had been guessing at for decades. That doesn't make them beyond critique, and plenty of thoughtful engineers have pushed back on aspects of the methodology over the years, but it does explain why the four specific metrics have staying power rather than being replaced every couple of years by the next framework.

The methodology also relied heavily on self-reported survey data rather than direct instrumentation of every participating organization's systems, which is a fair point of critique worth acknowledging. Self-reported data has known limitations, respondents can misremember or round their own numbers, and the organizations willing to participate in a detailed survey about their engineering practices may not be perfectly representative of the industry as a whole. The research team addressed this as best they could through statistical techniques and a large sample size, but it's a reasonable caveat for anyone treating the specific benchmark numbers as more precise than they really are, rather than as a general directional signal.

The DORA research groups organizations into performance categories, commonly labeled Elite, High, Medium, and Low, based on where their metrics fall across the four measures. An Elite performer, in the research's framing, might deploy on demand multiple times a day, have a lead time for changes measured in hours, a change failure rate in the low single digits, and restore service from an incident in under an hour. A Low performer might deploy less than once a month, have a lead time measured in months, a change failure rate well above the Elite range, and take a week or more to restore service after an incident.

These categories are useful as a rough benchmark, a way for a team to look at its own numbers and get a sense of where it stands relative to a large body of surveyed organizations, but they're easy to misuse if treated as a rigid ladder every team must climb regardless of context. A small internal tool used by a handful of people inside a company doesn't need Elite-level deployment frequency, and chasing that category for a system where it doesn't matter is a waste of engineering effort that could go toward something that actually moves the business forward.

The categories also shouldn't be read as a simple ranking where more of one metric is always better in isolation. A team should be suspicious of a rapid jump toward "Elite" deployment frequency if their change failure rate is also climbing, because that combination usually means quality controls got cut somewhere to hit the throughput number, not that the team suddenly got better at software delivery. Reading the four metrics together, and understanding the shape of the tradeoffs between them, matters more than fixating on any single category label.

It's also worth remembering that these benchmarks come from broad survey research across many industries and company types, and a specific organization's context, regulatory constraints, the criticality of the system, the size of the team, might reasonably put different target numbers in play. A team working on a safety-critical medical device system operates under real constraints that a team working on an internal marketing dashboard doesn't, and applying the same target lead time or deployment frequency to both without accounting for that difference misunderstands what the benchmarks are for.

DORA metrics fit well as a diagnostic starting point for a team or organization trying to understand where its delivery pipeline is actually struggling. If lead time is long, that points toward friction in code review, testing, or the deployment process itself, giving a team a concrete place to start investigating rather than a vague sense that things feel slow. If change failure rate is high, that points toward gaps in testing, code review rigor, or deployment safety practices like canary releases and feature flags. Used this way, the four metrics function like a set of vital signs a doctor checks first before deciding where to look more closely.

They fit poorly, and actively cause harm, when turned into individual or team performance targets disconnected from the underlying practice. The moment an engineering manager tells a team "get your deployment frequency to daily" as a target divorced from an honest look at whether the team's testing and review practices can support that safely, the team has a strong incentive to hit the number in ways that don't reflect real improvement, batching smaller, more trivial deployments to inflate the count, or quietly loosening review standards to move lead time down while change failure rate creeps up unnoticed until it becomes a real incident.

They also fit poorly as a cross-team comparison tool without heavy context. Comparing the deployment frequency of a team maintaining a mature, well-tested service against a team building a brand new system from scratch, or comparing a team working on a regulated financial system against a team working on an internal tool, produces numbers that look meaningfully different for reasons that have nothing to do with which team is better at software delivery. DORA metrics were designed and validated at the level of broad organizational research, not as a leaderboard for ranking teams against each other inside one company.

Where the framework genuinely earns its reputation is as a shared vocabulary that lets an engineering organization talk about delivery performance with more precision than "things feel slow" or "we ship a lot of bugs." That shared vocabulary, used honestly and paired with a genuine investment in fixing the practices the metrics point toward, rather than gaming the metrics themselves, is where DORA delivers real, durable value.

Executive reporting is a context where DORA metrics get misused in a subtler way, less through outright gaming and more through selective emphasis. It's tempting for an engineering leader to present the metrics that look good in a given quarter and quietly downplay the ones that don't, or to present a single blended number when the underlying stage-by-stage detail would tell a more complicated and less flattering story. The healthiest organizations report all four metrics together, consistently, whether the quarter's numbers are flattering or not, because a leadership team that only sees good news from its delivery metrics is set up to be blindsided when a real problem eventually surfaces in production.

Teams that introduce DORA metrics successfully start by measuring before they set any targets. Pulling the four numbers from existing deployment and incident data for a few months gives a team an honest baseline and, often, a useful surprise, teams frequently discover their actual lead time or change failure rate is quite different from what engineers assumed based on gut feel. Starting with measurement rather than goal-setting also avoids the trap of setting an arbitrary target before anyone understands what's realistically achievable given the team's current tooling and practices.

Framing matters enormously here. Introducing DORA metrics as a way to find and fix bottlenecks in the delivery pipeline lands very differently than introducing them as a new performance evaluation criterion. The first framing invites engineers to help diagnose problems, because a slow lead time becomes a shared puzzle to solve rather than a mark against anyone. The second framing invites exactly the gaming behavior that undermines the whole point of measuring in the first place, because now the incentive is to make the number look good rather than to make the underlying delivery process genuinely better.

Pairing the metrics with the specific engineering practices known to improve them tends to work better than presenting the numbers in isolation. Trunk-based development and small, frequent commits improve lead time and deployment frequency. Automated testing, canary deployments, and feature flags reduce change failure rate. Strong monitoring, alerting, and rehearsed incident response reduce time to restore service. Teams that understand the metrics are a byproduct of specific practices, not a target to chase directly, tend to improve the numbers as a natural side effect of getting genuinely better at the underlying work.

Finally, teams that keep DORA metrics useful over time revisit them periodically rather than treating the first measurement as permanent truth. A team's context changes: a new system gets more critical, a team grows, regulatory requirements shift. Checking back in on the four metrics every quarter or two, and being willing to update targets or even question whether a metric still makes sense given how the team's work has changed, keeps the framework a living diagnostic tool rather than a dusty dashboard nobody trusts anymore.

• Measure all four metrics together before setting any targets, since they only tell an honest story when read as a system, not individually.
• Use DORA metrics as a diagnostic starting point to find friction in the delivery pipeline, not as an individual or team performance target.
• Pair the metrics with the specific practices known to improve them, like small commits, automated testing, and canary deployments, rather than chasing the numbers directly.
• Avoid comparing DORA metrics across teams with very different contexts, like regulated systems versus internal tools, without accounting for that difference.
• Revisit your baseline and targets periodically, since a team's appropriate targets shift as the system's criticality, team size, or constraints change.

• DORA metrics are not a scorecard to hit; they were designed as a diagnostic tool built from research correlating specific measures with organizational performance.
• A higher deployment frequency is not automatically better if change failure rate is climbing at the same time; the four metrics need to be read together.
• DORA metrics do not measure individual engineer productivity, they measure the performance of the delivery pipeline and organizational practices as a whole.
• The Elite, High, Medium, Low categories are benchmarks from broad research, not a mandatory ladder every team or system must climb regardless of context.
• Improving DORA metrics is not about gaming the numbers directly, it's a byproduct of genuinely improving practices like testing, code review, and incident response.