DORA Metrics

Engineering leaders have long struggled to answer a simple question: is our software delivery getting better or worse? Lines of code, story points and hours worked say little about outcomes, and each team tends to invent its own measures. DORA metrics offer a common answer. They come from years of survey research run by DevOps Research and Assessment (DORA), a program started by Nicole Forsgren, Jez Humble and Gene Kim and now part of Google Cloud. The research found that a small set of delivery measures predicts both technical performance and wider business results, such as profitability and customer satisfaction.

The original four metrics cover two sides of delivery. Deployment frequency and lead time for changes measure throughput, or how fast change flows. Change failure rate and time to restore service measure stability, or how safely it flows. The central finding of the research is that the best teams do not trade one for the other: they ship more often and break less. For engineering leaders, platform teams and the executives who fund them, DORA metrics provide a shared, outcome-focused view of delivery performance.

Definition of DORA Metrics

DORA metrics are standardized measures of software delivery performance, covering the frequency of deployments, the time from code commit to production, the share of deployments that cause failures and the time needed to recover from them, used to compare and improve delivery over time.

They are a core part of engineering metrics, sit at the heart of DevOps practice and complement flow metrics, which look at the whole value stream rather than only the deployment pipeline.

The Four Key Metrics

Deployment frequency is how often a team successfully releases to production. High performers deploy on demand, often several times a day, while low performers may deploy monthly or less.

Lead time for changes is the time from a code commit to that code running in production. It reflects the speed of review, testing and release processes.

Change failure rate is the percentage of deployments that cause a failure in production requiring a fix, rollback or patch. It shows whether speed is coming at the expense of quality.

Time to restore service, renamed failed deployment recovery time in later DORA reports, is how long it takes to recover when a deployment causes a failure. It is closely related to mean time to recovery (MTTR).

How the Metrics Have Evolved

DORA publishes its research annually, and the model has been refined over time. Later reports added reliability as an operational measure and introduced rework rate, the share of deployments that are unplanned fixes for problems users found.

The reports group teams into performance clusters each year rather than fixing permanent thresholds. Teams should treat published benchmarks as a guide to direction, not as targets to hit exactly.

DORA has also studied the conditions that drive performance, such as continuous delivery, loosely coupled architecture, generative culture and good documentation, so the metrics come with evidence about what to change.

Importance of DORA Metrics in Software Delivery

DORA metrics give leaders a shared language. Instead of debating anecdotes, teams and executives can look at the same four numbers and agree on where delivery is slow or fragile.

They balance speed with stability. Because two metrics measure throughput and two measure failure, teams cannot improve their scores simply by shipping faster and accepting more incidents.

They also focus on outcomes rather than activity. The metrics measure what reaches customers and how reliably, not how busy engineers appear, which makes them harder to game than measures of individual output.

DORA Metrics and Financial Management

Long lead times tie up engineering investment in work that is finished but not yet delivering value to customers.

A high change failure rate creates rework, incident costs and lost revenue that rarely appear in project budgets.

Faster recovery limits the cost of each outage, which matters most for revenue-generating and customer-facing services.

Linking DORA trends to the cost of the teams and platforms involved helps leaders judge whether investments in automation and tooling are paying off.

Common Challenges

Teams often define the metrics differently, such as starting lead time at ticket creation instead of commit, which makes comparisons misleading. Agreeing on definitions first prevents this.

Using the metrics to rank or reward individual teams encourages gaming, such as splitting deployments to raise frequency. DORA intended them as tools for improvement, not performance reviews.

Collecting the data by hand is slow and unreliable. Most organizations need to pull it automatically from version control, CI/CD and incident tools.