How to measure and improve DevOps performance with DORA metrics

Modern software delivery is defined by how quickly and reliably you can ship value to users. The DevOps Research and Assessment (DORA) team at Google Cloud developed performance measurements called DORA metrics, which have become the industry standard for measuring DevOps success.

These four key metrics give teams a clear, data-backed way to assess their DevOps performance, pinpoint bottlenecks, and continuously improve.

In this blog, we’ll define these metrics, show you how to calculate them, and explore how they can build a high-performing DevOps culture.

What are DORA metrics? 

DORA metrics are four key indicators that measure the speed and stability of your software delivery process. They align directly with DevOps principles such as collaboration, automation, and continuous improvement, and focus on measurable outcomes rather than subjective or inconsistent measurements, like team-level productivity, or planning-oriented metrics like story points.

DORA metrics fall into two categories:

  • Velocity: How fast your team delivers (Deployment Frequency, Lead Time for Changes).

  • Stability: How reliable your releases are (Change Failure Rate, Time to Restore Service).

Together, they provide a holistic view of delivery performance.

The 4 key DORA metrics explained 

DORA metrics provide a structured way to evaluate how efficiently and reliably software teams deliver value. They group teams into performance tiers: Elite, High, Medium, and Low, based on delivery speed and stability. This helps organizations understand their current maturity and set clear goals for improvement. Let’s break down the four DORA metrics, how they work, and what benchmarks define elite performance.

1. Deployment Frequency

Definition:
How often your organization successfully deploys code to production (or releases updates to end users).

Why it matters:
Frequent deployments indicate smaller, safer changes and faster delivery of value. Elite teams deploy multiple times per day, enabling rapid feedback loops.

Benchmark:

Performance level

Deployment Frequency

Elite

On-demand/Multiple per day

High

Once per day to once per week

Medium

Once per week to once per month

Low

Less than once per month

Formula:
Deployment Frequency = Number of successful deployments / Time period

Example:

A team that deploys small updates twice a week and larger feature releases every two weeks shows a medium deployment frequency. This indicates they have some automation in place but still rely on manual checks for major releases.

2. Lead Time for Changes

Definition:
The time taken for a commit to get into production.

Why it matters:
Shorter lead times enable faster iteration and quicker user feedback, helping teams respond to market changes effectively.

Benchmark:

Performance level

Lead Time for Changes

Elite

<1 hour

High

1 day–1 week

Medium

1 week–1 month

Low

>6 months

Formula:
Lead Time for Changes = Deployment time – Commit time

Example:

If a developer commits code on Monday and it gets deployed to production by Thursday, the lead time is three days. This is common in teams that use automated testing but still require manual reviews and approvals.

3. Change Failure Rate

Definition:
The percentage of deployments that cause a failure in production, such as rollbacks, incidents, or hotfixes.

Why it matters:
This measures the stability of your delivery process. A low Change Failure Rate shows strong testing, monitoring, and release practices.

Benchmark:

Performance level

Change Failure Rate

Elite

0%–15%

High

15%–30%

Medium

30%–46%

Low

46%–60%

Formula:
Change Failure Rate = (Failed deployments / Total deployments) × 100

Example:

If a team pushes 10 releases in a month and two of them need rollbacks or critical fixes, the Change Failure Rate is 20%. This suggests there is a reasonably stable process, though improvements in testing or rollout strategies could reduce failures.

4. Time to Restore Service

Definition:
How long it takes to restore service after a production incident.

Why it matters:
Faster recovery minimizes user impact and shows strong observability and incident response processes.

Benchmark:

Performance level

Time to Restore Service

Elite

<1 hour

High

<1 day

Medium

1 day–1 week

Low

1 week–1 month

Formula:
Time to Restore Service = Median time between incident start and resolution

Example:

If an outage occurs in the afternoon and the team restores service within four hours after diagnosing and applying a fix, their Time to Restore Service reflects a typical high performance where alerts work well but root-cause analysis still takes time.

How to Calculate DORA metrics 

  1. Deployment Frequency:
    Count successful production deployments per week or month.

  2. Lead Time for Changes:
    Track the time difference between code commit and deployment.

  3. Change Failure Rate:
    Identify deployments that caused incidents or required rollback.

  4. Time to Restore Service:
    Calculate the median time to recover from each incident caused by a deployment.

You can also complement these metrics with milestone marker, that capture system performance at key events such as new releases or configuration changes. For instance, this feature lets you log a timestamped baseline of KPIs like response time or Apdex score and compare how performance shifts after each deployment. This helps teams correlate DORA metrics with real-world impact and visualize improvements over time.

Pro tips for accuracy: 

  • Use consistent definitions across teams.

  • Rely on automated data collection from CI/CD and incident management tools.

  • Prefer medians over averages to avoid outlier distortion.

Benefits of adopting DORA metrics 

Implementing DORA metrics can transform how your teams deliver software:

  • Objective benchmarking: Evaluate team performance with consistent KPIs.

  • Faster releases: Identify bottlenecks in your CI/CD pipeline.

  • Higher quality: Reduce deployment-related failures.

  • Data-driven culture: Empower teams with insights for continuous improvement.

  • Better collaboration: Align DevOps and QA around shared delivery goals.

Use cases and implementation challenges 

Use cases 

  • Engineering performance dashboards: Track DevOps maturity across teams.

  • Continuous improvement: Detect and fix process inefficiencies.

  • Incident post-mortems: Use Change Failure Rate and Time to Restore Service to gauge resilience progress.

  • Platform engineering: Guide investments in CI/CD speed and observability.

Challenges 

  • Data fragmentation: Metrics live across source code management, CI/CD, and incident systems.

  • Inconsistent definitions: Teams interpret deployments and incidents differently.

  • Metric gaming: Treating metrics as targets can encourage shallow optimizations.

  • Context loss: Numbers alone can’t explain why a metric worsened, pair them with retrospectives.

Best practices for implementing DORA metrics 

Dos 

  • Define terms like “deployment,” “failure,” and “incident” clearly.

  • Automate metric tracking through integrated dashboards.

  • Analyze trends, not one-off numbers.

  • Review metrics during retrospectives, not just reports.

  • Focus on balance, both speed and stability matter.

Don'ts 

  • Using DORA metrics to rate individual developers.

  • Optimizing one metric (e.g., speed) at the cost of another (e.g., reliability).

  • Ignoring contextual factors like team size or architecture complexity.

  • Comparing teams that work in vastly different environments.

Choosing the right DORA metrics solution 

When selecting a tool or platform to track DORA metrics, evaluate whether it has these key features:

  1. Data integrations: Supports your Git, CI/CD, and incident tools (GitHub, Jenkins, Jira, PagerDuty, etc.)

  2. Transparency: Shows how each metric is calculated and lets you drill down.

  3. Customization: Filter by team, service, or environment.

  4. Actionability: Provides insights, not just charts.

  5. Security: Offers RBAC and data governance for sensitive information.

Implementation roadmap for DORA metrics 

  1. Define metrics and KPIs for your teams.

  2. Identify data sources across code, CI/CD, and monitoring systems.

  3. Start small; measure one or two metrics for a pilot service.

  4. Automate and validate the data flow.

  5. Iterate and expand to more services, refining accuracy.

  6. Use trends to guide process improvements.

Using DORA metrics for continuous improvement 

DORA metrics are a proven, research-backed framework to measure the health of your DevOps process. They offer a unified language for engineering speed and reliability, helping teams ship faster, fail less, and recover quicker.

When implemented thoughtfully, DORA metrics do more than track performance; they drive a culture of continuous learning and improvement. Use them as a compass to guide smarter decisions, not a scoreboard, and watch your delivery performance reach elite levels.