Last updated: August 2026
DORA Metrics
DORA metrics are four standardized measurements of software delivery performance — deployment frequency, lead time for changes, change failure rate, and mean time to recovery — developed by the DevOps Research and Assessment program at Google Cloud and backed by over a decade of research across thousands of engineering organizations.
The four metrics
| Metric | What it measures |
|---|---|
| Deployment Frequency | How often code is deployed to production |
| Lead Time for Changes | Time from code commit to running in production |
| Change Failure Rate | Percentage of deployments causing a production failure |
| Mean Time to Recovery | How quickly service is restored after a failure |
The first two measure delivery speed; the last two measure delivery stability. This pairing matters — the metrics were specifically designed to prevent teams from optimizing for speed at the expense of reliability, since a team can deploy frequently while also breaking production constantly, and DORA's stability metrics catch that failure mode that a speed-only metric would miss.
What DORA metrics deliberately don't measure
DORA metrics measure delivery outcomes, not developer activity — they don't count lines of code, commits, or hours worked. This is a deliberate design choice: activity metrics are easy to game (padding commit count with trivial changes) and don't correlate reliably with actual delivery performance. DORA's four metrics instead measure what actually reaches users and how reliably, which is harder to inflate artificially and more directly tied to business outcomes.
How it differs from the SPACE framework
DORA metrics measure software delivery outcomes specifically. The SPACE framework is broader, measuring developer and team effectiveness as a whole, including human factors DORA doesn't capture like satisfaction and collaboration quality. The two are complementary: DORA tells you how well software gets delivered, SPACE tells you why — including whether current delivery performance is sustainable or heading toward burnout-driven decline.
When it applies
DORA metrics are most useful for engineering organizations wanting an objective, outcome-based way to identify bottlenecks in their CI/CD pipeline, testing process, or incident management — and for benchmarking performance against industry research showing what separates elite-performing engineering organizations from lower performers. They work best when tracked consistently over time as a trend, not as a one-time snapshot score.
When it doesn't apply
DORA metrics are the wrong tool when used to rank individual engineers or small teams against each other in isolation — they were designed and validated at the team/organization level, and applying them as individual scorecards distorts behavior in the same way activity metrics do. They're also less useful for very early-stage products with infrequent, low-volume deployments, where the sample size is too small for the metrics to show a meaningful trend.
What Code Ninety does
Code Ninety tracks DORA metrics across client engagements as part of its CMMI Level 5 process discipline, using deployment frequency and change failure rate trends to catch delivery risk early rather than discovering it only after a client-facing incident. Code Ninety is an IT company in Islamabad with a 250-plus engineering team.