Stage28 Team
23 Oct, 2024 5 min
How do you know whether your engineering organization is actually getting better at shipping software? Gut feel and story points will not tell you. The DORA metrics have become the industry standard for answering that question objectively. Google’s DevOps Research and Assessment team developed these four measures through years of research behind the Accelerate State of DevOps Report.
What makes DORA metrics powerful is the balance they strike: two metrics measure speed, two measure stability. Teams that optimize one at the expense of the other quickly see it in the numbers. This guide covers what each metric means, what good looks like, and how to improve.
What Are DORA Metrics?
DORA metrics are four indicators of software delivery performance: lead time for changes, deployment frequency, mean time to recovery, and change failure rate. Together they answer two questions every CTO cares about: how fast can we deliver value? and how reliably does it work when we do?
Because they are outcome-based rather than activity-based, they resist gaming better than metrics like velocity or lines of code. They also give leadership a common language for comparing teams, spotting bottlenecks, and tracking the impact of process investments over time.
The Four DORA Metrics Explained
1. Lead Time for Changes
Lead time measures the average time from code commit to running in production. It reflects the health of your entire delivery pipeline: code review, testing, integration, and deployment. Elite teams measure lead time in hours; struggling teams measure it in weeks.
If changes routinely take days or weeks to reach production, the bottleneck is usually in continuous integration, manual QA gates, or batch-oriented release processes rather than in the code itself.
2. Deployment Frequency
Deployment frequency measures how often you ship to production. High-performing teams deploy on demand, often several times a day. Low performers ship somewhere between once a week and once a month.
Deploying often can look reckless from the outside, but it is really a form of risk management. Small, frequent releases mean smaller blast radius per change, easier rollbacks, and faster feedback from real users.
3. Mean Time to Recovery (MTTR)
MTTR measures how long it takes to restore service after an incident. Recovering in under an hour is excellent; taking hours or days signals gaps in observability, incident response, or rollback capability. In modern operations, MTTR often matters more than avoiding failure entirely. Failures are inevitable; slow recovery is not.
4. Change Failure Rate
Change failure rate is the percentage of production changes that cause a failure requiring remediation. High performers stay below 15%. Rates above 30% point to quality problems upstream, such as thin test coverage, weak code review, or environments that do not mirror production.
How to Measure DORA Metrics
Accurate measurement requires instrumentation, not spreadsheets:
- Lead time: timestamp from commit to production deploy, pulled from your VCS and CD pipeline.
- Deployment frequency: count of production deploys per day, week, or month.
- MTTR: time from incident start to full recovery, from your incident management tool.
- Change failure rate: failed changes divided by total changes over a period.
Tools like GitLab, Jenkins, and CircleCI expose the pipeline data; Apache DevLake, Prometheus, and Grafana turn it into dashboards. Companies like Google and Netflix track these metrics continuously to keep delivery pipelines healthy across hundreds of teams.
How to Improve Each Metric
- Reduce lead time: invest in test automation and true continuous integration; kill manual approval steps that add wait time without adding safety. Automating environments with infrastructure as code removes a common source of delay.
- Increase deployment frequency: strengthen CI/CD infrastructure, decouple deploy from release with feature flags, and ship smaller batches.
- Reduce MTTR: improve observability, define incident runbooks, automate rollbacks, and rehearse failure scenarios.
- Lower change failure rate: enforce meaningful code review, raise test coverage where it counts, and make staging faithfully mirror production.
Architecture matters too. Loosely coupled systems, such as well-designed microservices, let teams deploy independently, which lifts frequency and shrinks lead time without coordination overhead.
Common Pitfalls to Avoid
Do not weaponize the metrics. Using DORA numbers to rank teams or individuals invites gaming and destroys the trust the metrics depend on. They are a diagnostic for improving the system, not a scoreboard for judging people. Also resist comparing raw numbers across teams with very different contexts. A team maintaining a regulated payments system will not, and should not, deploy like a team running an internal tool.
Frequently Asked Questions
What are elite DORA benchmarks?
Roughly: deploy on demand (multiple times daily), lead time under one day, MTTR under one hour, and change failure rate below 15%. Most organizations are not elite, and that is fine. The point is to trend in the right direction, not to hit the benchmark on day one.
Are DORA metrics enough on their own?
No. They measure delivery performance, not product value or developer experience. Pair them with user-facing outcomes and team health signals for a complete picture.
How long before we see improvement?
Teams that invest in automation and smaller batch sizes typically see measurable movement within one to two quarters. The metrics compound: better lead time enables more frequent deploys, which reduces failure rates.
Ship Faster Without Breaking Things
DORA metrics give you the map; disciplined engineering gets you there. At Stage28, our AI-native senior engineers build and deliver software as fixed-scope, fixed-price projects, with payment only after delivery, and we bring elite delivery practices to every engagement. If you want a delivery pipeline your metrics can be proud of, get in touch.
