DORA metrics are the software delivery performance measures defined by the DORA research program: change lead time, deployment frequency and failed deployment recovery time describe throughput, while change fail rate and deployment rework rate describe instability. Together they show how quickly and how safely a team ships changes to production.
What are DORA metrics?
DORA metrics are a small set of measures for software delivery performance that come from the DORA (DevOps Research and Assessment) research program, now part of Google Cloud. The research started in 2014 and produced the well-known "four keys" that were popularized by the annual State of DevOps reports and the book Accelerate. The model has evolved since then: in 2023 the recovery metric was renamed from MTTR to failed deployment recovery time, and in 2024 DORA added deployment rework rate as a fifth metric.
The core idea is that speed and stability are not a trade-off. Teams that deploy small changes often also tend to have fewer failures and recover faster, so the metrics are always read together rather than individually.
The five DORA metrics
DORA currently groups its metrics into two factors, throughput and instability:
| Metric | Factor | What it measures |
|---|---|---|
| Change lead time | Throughput | Time from a change being committed to version control until it runs in production |
| Deployment frequency | Throughput | How often changes are deployed to production in a given period |
| Failed deployment recovery time | Throughput | How long it takes to recover from a deployment that fails and needs immediate intervention |
| Change fail rate | Instability | Share of deployments that need immediate intervention, such as a rollback or hotfix |
| Deployment rework rate | Instability | Share of deployments that are unplanned and happen because of an incident in production |
Failed deployment recovery time is deliberately narrower than a general MTTR: it only covers failures caused by a change, not outages from a cloud region, a hardware fault or a third-party API. That keeps the metric focused on the delivery process the team actually controls.
How to measure DORA metrics
The data for all five metrics already exists in your toolchain; the work is connecting it consistently.
- Commits and merges from version control give the start of change lead time.
- Deployment events from CI/CD give deployment frequency and the end of lead time. Each event should carry service, version, environment and commit SHA.
- Incidents, rollbacks and hotfixes from incident management and the pipeline mark which deployments failed and which follow-up deployments were unplanned rework.
- Recovery is the time between the failed deployment being detected and service being restored, ideally confirmed by telemetry rather than by a ticket status.
Illustrative example: a team ships 60 deployments in a month. Four needed a rollback or hotfix, so the change fail rate is 4 / 60 = 6.7%. Three further deployments were unplanned fixes for production incidents, so the deployment rework rate is 3 / 60 = 5%. The median recovery time of the four failures was 38 minutes. Neither number says much alone; the trend across several months does.
Why DORA metrics matter
DORA metrics give engineering leaders and teams a shared language that is based on outcomes, not activity. Lines of code, story points or ticket counts are easy to game and say nothing about whether users get working software. DORA metrics, by contrast, connect directly to reliability practices: a high change fail rate points to weak testing or risky release strategies, a long lead time to large batches or slow reviews, and a long recovery time to missing observability or unclear runbooks. They complement SLOs, which describe the user-facing reliability that delivery must protect.
Best practices
- Measure per service or team, not per company. An aggregate hides the services that need help.
- Use the metrics for improvement, not for ranking. DORA itself warns against turning them into individual targets.
- Automate collection. Manually reported numbers drift and are rarely trusted.
- Reduce batch size. Smaller changes, feature flags and canary deployments improve throughput and instability at the same time.
- Learn from failures. Every failed deployment deserves a short, blameless postmortem.
Common mistakes
- Optimizing deployment frequency alone, for example by splitting one change into many trivial deploys.
- Counting every incident as a failed deployment, which mixes infrastructure outages into a delivery metric.
- Still using the outdated "MTTR" definition and comparing it with current DORA benchmarks.
- Comparing teams with very different systems against each other instead of against their own baseline.
How Obseria helps
Obseria's deployment tracking records deployment events with version and service and correlates them with traces, errors and SLOs, so you can see which deployment degraded a service and when it recovered. Combined with incident management and automation workflows, this provides the telemetry side of failed deployments and recovery time; lead time from commit to deploy still comes from your version control and CI/CD system.