Guide
DORA metrics, explained properly.
DORA metrics are four measures of software delivery performance identified by the DevOps Research and Assessment programme: deployment frequency, lead time for changes, change failure rate, and time to restore service. The first two measure throughput, the second two measure stability — and the central finding is that they rise together rather than trading off against each other.
Why these four, and not others
The DORA programme’s useful contribution was not inventing new measures. It was demonstrating, across many years of survey data, that these four correlate with organisational performance, and that the assumed trade-off between speed and stability does not exist. Teams that deploy more often also break production less often. That single finding is why the four keys became a standard rather than one more framework.
They are also deliberately about the system rather than the people in it. None of the four can be attributed to an individual, which is what makes them safe to publish inside an engineering organisation. A measure that can be traced to a named person stops describing the system and starts describing a negotiation.
The two throughput metrics
Deployment frequency is how often you successfully release to production. It sounds trivial and is the one most often measured wrongly, because a great many teams substitute "merges to the main branch" for "deployments" and then wonder why the number does not match their release calendar.
Lead time for changes is how long a change takes to get from committed to running in production. It is the single most diagnostic of the four, because it can be split into stages — writing the code, waiting for review, being reviewed, waiting to merge and deploy — and the split almost always points somewhere unexpected.
The two stability metrics
Change failure rate is the proportion of deployments that cause a degradation in production requiring remediation — a hotfix, a rollback, a patch. It is not the proportion of deployments containing any bug at all, and conflating the two produces an alarming number that no one can act on.
Time to restore service — often written as MTTR — is how long it takes to recover once a change has caused a problem. It is the most direct measure of how confidently an organisation can ship, because the real cost of a failure is its duration rather than its occurrence.
Where DORA stops being enough
Four numbers describe how a delivery system behaves. They do not tell you whether the work was worth doing, whether the roadmap will land, whether testing is the constraint, or what the team thinks about any of it. In 2026, they also do not capture the impact of AI-assisted development, which is why almost every platform in this category now reports AI adoption alongside them.
The practical conclusion is to treat the four keys as the floor. Useful, standard, comparable — and not, on their own, an answer to any question a board asks.
The performance bands
The exact thresholds move slightly between annual DORA reports and the number of bands has changed more than once. These are the values in general use; treat them as a scale, not a specification.
| Metric | Elite | High | Medium | Low |
|---|---|---|---|---|
| Deployment frequency | On demand, multiple per day | Daily to weekly | Weekly to monthly | Less than monthly |
| Lead time for changes | Less than one day | One day to one week | One week to one month | More than one month |
| Change failure rate | Around 5% | Around 10% | Around 15% | Above 30% |
| Time to restore service | Less than one hour | Less than one day | One day to one week | More than one week |
Bands are useful for orientation and dangerous as targets. An organisation deploying medical device firmware is not failing because it does not deploy on demand.
Where this measure goes wrong
Each of these produces a number that looks reasonable and is not.
Using merges to main as a proxy for deployments
For any team that batches releases, this measures something else entirely and inflates deployment frequency dramatically. Deployment frequency should come from deployment events.
Counting every bug as a change failure
Change failure rate is about deployments that degraded production and needed remediation. Counting every defect found anywhere produces a figure that is both alarming and useless.
Reporting a snapshot instead of a trend
A single quarter’s figure tells you almost nothing. The question leadership actually asks is whether it is improving, which requires the series.
Treating the bands as targets
Elite is a description of a population, not a goal for every team. A team that moves from low to medium has done something genuinely valuable.
Rendering a zero where configuration is missing
If nobody has defined what counts as a failure on your Jira site, the honest change failure rate is "not configured", not 0%. A plausible wrong number gets quoted in a board meeting; an obviously missing one gets fixed.
Frequently asked questions
What does DORA stand for?
DevOps Research and Assessment — the research programme, begun by Nicole Forsgren, Jez Humble and Gene Kim, that identified the four metrics through several years of industry survey data. It was acquired by Google in 2018 and continues to publish an annual State of DevOps report.
Are there four DORA metrics or five?
The core set is four. Later reports have experimented with a fifth measure of reliability or operational performance, and the exact framing has shifted between years. Nearly all tooling, including Pacia, reports the four.
Can DORA metrics be used to evaluate individual engineers?
No, and attempting it is the most common way organisations destroy the value of the metrics. All four are properties of a delivery system. Attributing them to a person makes them trivially gameable and turns every subsequent figure into a negotiation.
How long does it take to get DORA metrics from a tool?
With a platform that backfills history, the same day. Pacia pages through up to 180 days of pull request history the moment a repository is connected, so trends exist immediately rather than after a quarter of data collection.
Do DORA metrics still matter in 2026?
They remain the standard vocabulary for delivery performance and the only widely comparable one. What has changed is that they no longer cover the whole question — they say nothing about AI-assisted development, about whether the work was worth doing, or about how the team is holding up.
See dora metrics for your own teams
Pacia computes this from your repositories and issue tracker, banded and trended, with a drill-down to the work behind every figure.