DORA Metrics: Software Delivery Performance Guide

DORA metrics are performance indicators that measure the effectiveness of an organization’s software development and delivery practices. They were designed by the DevOps Research and Assessment (DORA) group based on seven years of research and insights from 39,000 industry professionals.

DORA metrics provide an evidence-based system for measuring the performance of a continuous integration and continuous deployment (CI/CD) pipeline.

DORA originally focused on four key software delivery metrics:

• Deployment frequency
• Lead time for changes
• Change failure rate
• Time to restore service

More recently, a complementary fifth metric was introduced to help teams understand how well systems meet user expectations:

• Reliability

The original DORA metrics are often broken into two categories that capture how quickly teams deliver changes and how often those changes create disruption: throughput and instability.

What are throughput metrics?

Throughput metrics measure velocity, or how quickly a DevOps team can move software changes from development to production. High throughput helps teams respond faster to market shifts, customer feedback, and product opportunities.

DORA’s throughput metrics include:

• Deployment frequency: How often developers deploy new code
• Lead time for changes: How long it takes for new code to reach production

What are instability metrics?

Instability metrics measure code quality and resilience. Stability must be balanced with delivery speed to avoid costly errors, rework, service outages, and security vulnerabilities.

DORA’s instability metrics are:

• Change failure rate: How often a change causes a failure (e.g., outages or rollbacks).
• Time to restore service: How long it takes to restore service after an outage.

Each DORA metric offers a different lens into the speed, quality, and resilience of your software delivery process. Let’s take a closer look at what defines these metrics and how to improve them.

What is deployment frequency?

Deployment frequency measures how often a development team successfully deploys code to production. This can range from a few deployments per month to multiple deployments per day.

A higher deployment frequency can indicate that a team can deliver bug fixes, product updates, and new features more quickly. It is often used as a signal of delivery agility and responsiveness.

Deployment frequency is typically measured by tracking the number of successful production deployments over a set period of time.

Improving deployment frequency starts with understanding where delivery slows down (e.g., testing, code review, approvals, or release coordination). Benchmarks can show how current performance compares to peers, but the bigger opportunity is finding the workflow issues that are causing delays.

For example, common actions that teams take to reduce friction across their delivery processes include:

• Automating testing and validation throughout the CI/CD pipeline
• Reducing manual approvals and handoffs that slow releases
• Breaking changes into smaller, more manageable iterations
• Improving pipeline performance and deployment reliability

What is lead time for changes?

Lead time for changes measures how long it takes for committed code to reach production. A shorter lead time generally indicates a more efficient and responsive software delivery process.

Lead time for changes is calculated as the time between code commit and successful deployment to production.

A long lead time for changes often means code is spending too much time waiting — in review queues, test environments, approval steps, or other parts of the delivery process.

To improve this metric, teams focus on things like:

• Using value stream mapping to identify where work is waiting between stages
• Reducing merge request review delays and unnecessary approval steps
• Using on-demand environments to speed up validation and testing
• Shortening feedback loops so issues are caught and resolved earlier

What is change failure rate?

Change failure rate measures the percentage of production deployments that result in an incident, degraded service, rollback, or other failure requiring remediation. A high rate might indicate issues with release quality, testing, deployment safety, or operational readiness.

Change failure rate is calculated by dividing the number of production incidents by the number of production deployments over a given time period.

Change failure rate is difficult to track for a few reasons. One is that the definition of “failure” may vary from one organization to the next. For example, should slow load times caused by a new release be treated the same as a complete service outage?

Another challenge is that the data needed to measure change failure rate often lives across disconnected systems, such as deployment logs, incident management tools, and observability platforms. Without a clear way to connect production incidents back to the changes that caused them, this metric can be difficult to track accurately.

Reducing change failure rate starts with understanding which releases are creating avoidable production issues, and why. The goal is to improve release quality without unnecessarily slowing delivery.

To reduce this metric, teams often focus on:

• Shifting security and quality checks earlier in the development lifecycle
• Automating test coverage and validation before changes reach production
• Using production-like environments to catch issues before release
• Using phased or incremental rollouts for higher-risk changes

What is time to restore service?

Time to restore service (sometimes referred to as mean time to recovery, or MTTR) measures how long it takes to recover from a production incident or service disruption. A shorter recovery time indicates that teams can quickly resolve incidents, minimizing the impact on end users.

Time to restore service is calculated by tracking the amount of time between the start of a production incident and full service restoration.

Even the most mature organizations experience production incidents. Rather than focusing on complete prevention, software teams should work toward:

• Improving observability and alerting to detect incidents earlier
• Reducing lead time for changes so fixes can be deployed more quickly
• Standardizing incident response and recovery workflows

Software delivery has a direct impact on business performance. To enhance how organizations innovate and deliver value, DORA metrics provide a consistent framework for measuring delivery performance and identifying opportunities for improvement. They allow teams to:

• Identify workflow bottlenecks and visibility gaps that slow delivery
• Make more informed decisions using consistent, data-backed insights
• Align software delivery improvements with broader business and customer goals
• Reduce manual work and rework so developers can focus on higher-value work

Example of DORA metrics in action

Imagine a growing technology company notices its deployment frequency has been trending downward, even as the engineering team expands. After investigating the issue, the team discovers that developers are spending hours — sometimes days — waiting for access to a shared staging environment before they can validate and release new code.

Using deployment frequency and lead time data, the organization identifies environment availability as a major source of delivery friction. To address the issue, the team adopts scalable, cloud-based Kubernetes environments that can be provisioned on demand for testing and validation.

As a result, developers spend less time waiting for resources, deployments move through the pipeline more quickly, and the organization can release updates faster and more consistently.

Value stream management (VSM) helps organizations understand how work moves through the software delivery lifecycle. While DORA metrics measure delivery performance, value stream management provides the broader operational context needed to identify where delays, inefficiencies, and workflow friction are occurring.

By mapping the full delivery workflow — from planning and development through testing, deployment, and incident response — teams can better understand how their processes influence DORA metrics and overall software delivery performance.

A unified orchestration platform like GitLab can help teams connect DORA metrics to the workflows, approvals, environments, and handoffs that shape delivery outcomes. With shared visibility across the entire lifecycle, organizations can ultimately make more informed improvements that support both engineering efficiency and business goals.

Learn how GitLab supports DORA Metrics and Value Stream Management.