What Are DORA Metrics? The Four Keys Every Dev Needs
Summary
DORA metrics are four measurements that reveal how fast and reliably a software team delivers code. They cover deployment frequency, lead time for changes, change failure rate, and how quickly the team recovers from failures in production. Developed by the Google-acquired DevOps Research and Assessment group and validated across thousands of engineering teams, they remain the baseline framework for measuring software delivery. This guide explains what each metric tracks, what elite performance looks like, and where the model stops being useful.
If you've been asked what are DORA metrics and needed a clean answer: they are four measurements that quantify software delivery performance. Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service. Developed by Nicole Forsgren, Jez Humble, and Gene Kim, validated across tens of thousands of engineering teams, and acquired by Google in 2018. This guide covers what each metric tracks, what the benchmarks look like in practice, and where the model stops being the right lens.
Where DORA metrics came from and why the research matters
The DORA program started in 2014 with a specific question: what do high-performing software teams do differently from everyone else? The research team ran annual surveys of tens of thousands of developers across industries, looking for the practices that predicted strong software delivery outcomes.
The finding that made the research stick was counterintuitive. Elite teams did not trade speed for stability. They shipped faster and had fewer production incidents. That result undercut the standard justification for slowing down release cycles: if we deploy less often, we will break things less often.
The data said the opposite. Teams that deployed frequently built better feedback loops, caught problems earlier, and recovered faster when something did go wrong. Speed and stability were not in opposition. They were correlated.
Google acquired the DORA program in 2018. The team now publishes an annual State of DevOps Report, updated its model in 2025 with a fifth metric (Rework Rate), and maintains the research as an open initiative at dora.dev.
The four measurements and what each one actually tracks
The model was updated in 2025 to add Rework Rate as a fifth metric, but the four original keys remain the baseline for most tooling and team discussions.
Deployment Frequency
How often your team pushes to production. That is the full definition.
Elite teams deploy on demand: multiple times per day when something is ready. Low performers deploy once a month or less, sometimes once every few months. For a solo builder, any consistent weekly shipping cadence puts you solidly in the high-performing bracket by this single measure.
Deployment frequency is a proxy for pipeline confidence. Teams deploying infrequently usually have fragile infrastructure, heavy manual testing gates, or organizational approval chains that slow releases to a crawl. Teams that ship multiple times daily have automated away most of those bottlenecks. The frequency is a symptom, not the cause.
Lead Time for Changes
The time from a commit reaching version control to that same change being live in production.
Most of this duration is not writing code. It is waiting: waiting for the pull request queue to clear, waiting for CI/CD pipelines to finish, waiting for a deployment slot, waiting for someone with access to trigger the release. A lead time of a few hours means the workflow is tight and largely automated. A lead time measured in weeks means something structural is adding friction at one or more of those handoff points.
For solo developers, lead time is whatever stands between pushing a commit and users seeing the result. Sometimes that is a deployment pipeline that takes twelve minutes. Sometimes it is internal hesitation about whether a change is stable enough to ship.
Change Failure Rate
The percentage of deployments that cause a problem serious enough to require a hotfix, rollback, or incident response.
This is the quality signal in the DORA model. The 2024 State of DevOps Report puts elite teams at around 5% change failure rate. Low performers run at 46 to 63%. If roughly half your deployments require immediate intervention, your testing coverage and review process have significant structural gaps.
Change failure rate does not measure code quality in the abstract. It measures whether the changes you ship behave as expected in the production environment specifically. A test suite that passes locally but does not cover the integration paths that fail in production will not move this number.
Time to Restore Service
When a deployment causes an incident, how long before service is restored?
This was originally labeled Mean Time to Recovery (MTTR). The DORA team updated the framing in 2025 to Failed Deployment Recovery Time, specifically tracking recovery from deployment-caused incidents rather than infrastructure failures or third-party outages. The distinction matters because deployment-caused incidents are fully within the team's control, which makes them the right target for process improvement.
Elite teams restore service in under an hour. Low performers can take days to a week. If you are a solo builder, this metric is largely about whether you have monitoring in place at all. Teams without alerting infrastructure find out about failures from user complaints rather than automated signals, which adds hours to any recovery time.
What the performance tiers actually look like
The State of DevOps report groups teams into four tiers based on their DORA numbers. These are rough ranges from the 2024 report, not hard cutoffs:
| Tier | Deployment Frequency | Lead Time | Change Failure Rate | Recovery Time | |---|---|---|---| ---| | Elite | Multiple times per day | Under 1 hour | Under 5% | Under 1 hour | | High | Daily to weekly | 1 day to 1 week | 5-10% | Under 1 day | | Medium | Weekly to monthly | 1 week to 1 month | 10-15% | 1 day to 1 week | | Low | Monthly or less | 1 to 6 months | 46-63% | 1 week to 6 months |
The gap between elite and low is not incremental. According to the 2024 report, low-performing teams can take over 180 times longer to deploy and more than 2,500 times longer to recover from incidents compared to elite teams. These are not marginal differences.
Reaching elite tier is achievable with sustained investment in CI/CD automation, test coverage, and observability tooling. It does not happen by writing faster code. It happens by removing the manual steps and waiting periods between committing code and having it run in production reliably.
How AI development tools are shifting DORA numbers in 2026
By 2026, AI coding tools have become common enough to affect DORA metrics in ways worth tracking specifically.
Teams using Cursor, GitHub Copilot, or similar tools are writing code faster, which tends to push deployment frequency up. Lead time has also shortened at many teams because more code is produced per developer per week, which means more commits flowing through the pipeline.
Change failure rate has gone in both directions. Teams with strong review processes and test coverage have held their failure rates stable while shipping more. Teams that ship AI-generated code without adequate review have seen failure rates increase. The DORA model does not care how code is written. It measures what happens after the code ships to production.
The DORA 2024 State of DevOps Report found that 41% of surveyed teams reported using AI-assisted development tools. Those teams showed higher deployment frequency without a proportional increase in change failure rate when AI adoption was paired with automated testing and review pipelines.
Voila ce qui coince en pratique: AI accelerates the front end of the pipeline significantly. DORA tells you whether that acceleration is being absorbed cleanly or creating instability downstream.
Tools for tracking DORA metrics without overbuilding your stack
Most teams start measuring DORA metrics by pulling data from tools they already use: GitHub or GitLab for deployment events and commit timestamps, PagerDuty or OpsGenie for recovery time data, and the incident management system for change failure rate counts.
Several platforms have built DORA dashboards specifically around these four metrics:
For a solo builder without a tooling budget: a script that logs the timestamp of each production deployment and each recovery event gives you deployment frequency and recovery time with no infrastructure cost. Lead time can be approximated from commit timestamps in the Git log.
Where DORA metrics have real limits
Measuring DORA is useful. Treating it as the complete picture of engineering performance creates several specific blind spots worth naming.
Technical debt accumulation. High deployment frequency with a low change failure rate tells you nothing about whether the codebase is becoming harder to work with over time. A team can hit elite DORA numbers while steadily accumulating the kind of debt that makes every new feature slower to ship. DORA measures delivery output; it does not measure the state of what you are delivering into.
Outcome alignment. Deployment frequency measures output, not outcomes. Shipping five times per day does not matter if none of those changes move a metric that the product or business cares about. Feature flags, A/B testing infrastructure, and business metrics tracking sit outside the DORA model entirely.
Sustainability. The DORA research team added a developer experience dimension to the framework in 2023, acknowledging that sustainable high performance requires engineers who are not running on burnout. The four core metrics do not track whether hitting elite numbers is coming at a cost elsewhere.
Use DORA as a baseline diagnostic tool, not a scoreboard. The questions the metrics raise are often more actionable than the numbers themselves. A change failure rate of 30% is less useful than knowing which types of changes fail most often and why.
Where to start if you have never tracked these before
A six-month-old side project with no DORA data is normal. Most small teams and solo builders have never measured any of this.
If you are starting from zero, pick deployment frequency and lead time first. Both are easy to extract from Git commit timestamps and deployment logs, and they give you immediate feedback on whether your pipeline has unnecessary friction. A lead time of three days for a change that takes forty minutes to write is a signal worth investigating.
Change failure rate and time to restore require incidents to accumulate before the numbers mean anything. When something breaks in production, log the timestamp it was detected and the timestamp it was resolved. That data compounds over time.
A practical habit: after any production incident, ask two questions. How long did it take to detect this problem? How long from detection to resolution? Those two numbers are the inputs to time to restore. Tracking them consistently for six months gives you enough history to know whether your recovery process is improving or staying flat.
Three reasons to measure DORA metrics even as a solo dev, one reason not to bother: the metrics make invisible friction visible, they create accountability for automation investments, and they give you something concrete to improve between feature work. The reason not to bother: if you are pre-launch with no production users, the numbers do not mean much yet. Start measuring when you are shipping to real users regularly.
Ce n'est pas une idee parfaite. C'est une idee faisable.