DORA Metrics Explained: The Key DevOps Performance Metrics to Track

Your team ships code continuously, but can you say whether you’re getting better at it? You need a yardstick that shows how quickly your changes reach production and how often they disrupt it. Those consistent numbers also let you compare your results with historical benchmarks.

This guide covers the current five-metric DevOps Research and Assessment (DORA) model and the final Elite-to-Low benchmarks. It connects the historical four metrics with today’s model and explains why each tool’s definition must match DORA’s before benchmarking.

What Is DORA?

DORA is the DevOps Research and Assessment program, which Nicole Forsgren and colleagues founded before Google acquired it. The program now publishes through dora.dev as part of Google Cloud. It aims to understand the capabilities that drive software delivery and operations performance and help you apply them.

The Five DORA Metrics Explained

DORA began with deployment frequency, lead time, and recovery time, added change failure rate later, and introduced deployment rework rate in 2024.

The current model sorts metrics into factors: Software Delivery Throughput includes change lead time, deployment frequency, and failed deployment recovery time, while Software Delivery Instability includes change fail rate and deployment rework rate.

Tool documentation may still use the older names, so each section gives both, while the benchmark table presents the final Elite, High, Medium, and Low tiers.

Deployment Frequency

Deployment frequency counts how often you push code to production. It can represent the number of deployments during a period or the time between deployments.

It provides context on batch size and continuous integration and continuous delivery (CI/CD) cadence: on-demand deploys may stay small, while monthly deploys may bundle weeks of work.

The final tiers classified deployment cadence from multiple daily deploys for Elite performers to monthly or semiannual deploys for Low performers.

Lead Time for Changes

Lead time for changes measures the elapsed time from a code commit until that code runs in production. The elapsed time covers review, build, test, and deployment.

The current model calls this metric change lead time, with final tier ranges extending from under one day for Elite performers to one to six months for Low performers.

Tools can choose different starting points. Some calculations begin at merge time and exclude coding and review, while others begin when you create the commit, which matches DORA’s definition. The tool’s definition should be checked before benchmarking its figure against DORA thresholds, or the comparison may make delivery look faster than it is.

Change Failure Rate

Change failure rate, which the current model calls change fail rate, measures the share of production deployments that need immediate intervention, such as a rollback or hotfix. The formula divides failures by deployments, so four daily deployments with one failure produce a 25 percent change failure rate.

When you investigate high rates, examine whether large batch sizes compound missing automated tests and incomplete monitoring coverage. Proactive failure notification helps you diagnose and solve problems quickly instead of waiting for customers to report them.

The benchmark tiers don’t progress uniformly on this metric, which reminds you that rarely deploying to preserve a low failure rate isn’t the goal.

Time to Restore Service

Teams long tracked time to restore service as mean time to recover (MTTR), which measures how long a change-induced production failure lasts. DORA later renamed it “failed deployment recovery time” and narrowed the scope to failures a deployment causes, meaning a data center outage no longer counts against your pipeline.

Recovery-time benchmarks range from under one hour for Elite performers to one week to one month for Low performers. Your observability practice supplies the data behind this metric, since every recovery starts with detection and moves through diagnosis and repair. Practices that reduce MTTR target delays across both intervals.

AI-native observability platforms shorten the diagnostic interval by correlating telemetry automatically. Coralogix’s autonomous observability agent, Olly, correlates log and metric data with traces to identify which deploy sits behind a failing checkout or payments service.

Reliability vs. Deployment Rework Rate: Which Is the Fifth Metric?

Reliability later became the fifth DORA metric, and older guides still repeat that framing. The current model treats reliability as operational performance rather than software delivery performance and uses “deployment rework rate” as the fifth delivery metric.

DORA added deployment rework rate in 2024 and defines it as the ratio of unplanned deployments that respond to production incidents, so you divide unplanned deployments by total deployments. It sits beside change fail rate under the Instability factor and catches what change fail rate misses: a deploy that survived without a rollback, but forced an unplanned follow-up release.

Reliability still belongs on your dashboard as the operational counterpart, which you can track against service level objectives (SLOs).

Throughput vs. Stability: How the Metrics Work Together

Reading throughput and stability together keeps a team from optimizing one set of metrics at the expense of the other.

The classic reading treats deployment frequency and lead time for changes as throughput metrics, with change failure rate and time to restore service as stability metrics. DORA changed that grouping in 2024, moving failed deployment recovery time into Throughput and pairing change fail rate with deployment rework rate under Instability.

Reading one axis alone rewards the wrong behavior. You can double deployment frequency by shipping riskier changes and watch rework climb, or keep change fail rate near zero by deploying quarterly and learning little from production.

Top performers do well across all five metrics, while low performers do poorly, which means speed and stability move together when your delivery system is healthy. That balance provides context before you compare your results with performance tiers.

DORA Performance Tiers: Elite, High, Medium, and Low

DORA derives its tiers with latent profile analysis, which lets clusters emerge from each year’s survey data. Later editions replaced the four tiers with team archetypes based on a broader measure set, though the final published four-tier table still serves as a practical reference for target-setting.

The thresholds below come from the 2024 DORA report and cover deployment frequency, lead time, change failure rate, and recovery time across each performance cluster.

Metric	Elite	High	Medium	Low
Deployment frequency benchmarks	Multiple daily deploys	Daily to weekly	Weekly to monthly	Monthly to semiannual
Lead time benchmarks	Under one day	One day to week	One week to month	One to six months
Change failure benchmarks	About 5%	About 20%	About 10%	About 40%
Recovery time benchmarks	Under one hour	Under one day	Under one day	One week to month

Deployment rework rate joined the current model, but no four-tier thresholds are available for it. Respondents appeared throughout the tiers, and the Medium cluster was among them. Earlier editions produced different cluster patterns, including an edition without an Elite group, which is why your own trend line offers more durable context than any single annual label.

Why DORA Metrics Matter

The five metrics earn their place on your dashboard because they describe delivery performance across throughput, instability, and recovery without collapsing everything into a single score. That combination gives your team three practical uses:

• Objective comparison: DORA metrics replace “we ship pretty often” with numbers you can set against your own history and published benchmarks. Since tiers shift between reports, your own trend line provides the more useful comparison.
• A continuous improvement loop: The metrics act as a compass that orients your team toward better software faster, which means each measurement cycle should end with one named bottleneck and one focused change.
• Alignment with business outcomes: Faster, safer delivery reduces what incidents cost and gets product changes to users sooner.

A single reading rarely supports any of these uses. You gain more value when you measure the same five numbers consistently over time and interpret them together, and that longitudinal view also helps you avoid the implementation pitfalls that distort individual metrics.

Common Pitfalls When Implementing DORA Metrics

DORA rollouts often fail for the same reasons. Teams either treat diagnostic measures as targets or pull data from the wrong scope, and both problems distort the resulting numbers.

The four pitfalls below are the ones that most often derail a rollout:

• Setting metrics as goals: Goodhart’s law applies here. A mandate that “every application must deploy multiple times per day by year’s end” pushes teams to game the numbers, and treating system-level metrics as individual goals compounds that risk.
• Measuring throughput and ignoring stability: Chasing deployment frequency alone can produce an unstable production environment, and a rollback strategy may keep recovery time low while pulling the latest release away from users and distorting lead time. Reading both axes together lets you choose metrics that create healthy tension between them.
• Ranking teams instead of diagnosing services: The metrics work at the application or service level, which means comparing a mobile app with a mainframe system misleads you, as does blending metrics across an organization. A rolled-up number hides the bottleneck you wanted to find.
• Measuring the CI pipeline instead of the change lifecycle: A pipeline-scoped metric can miss deployment events that other systems record, such as a hotfix an engineer pushes from a laptop overnight. Narrow lifecycle monitoring hides parts of your delivery process.

Each pitfall produces numbers that look healthy on a dashboard but poorly represent your delivery system. Checking the definition behind a number costs less than acting on the wrong one, which is why clear definitions matter before instrumentation.

How to Start Measuring DORA Metrics

You can produce usable DORA numbers before you instrument anything. Shared definitions and a clear system of record come first, and the calculations that follow should cover the complete change lifecycle. Work through these four steps in order:

1. Define “deployment” and “production failure” first: A deployment must mean the same thing in every system that reports one, and only production deployments count. Write down what qualifies as a failure, which is a change your team releases to users that causes service degradation and requires remediation. Decide which incident tool will act as the system of record before you start collecting numbers.
2. Choose a calculation path: Measurement options range from native dashboards to third-party DORA tools built for pipelines that span several systems. Community-built integrations and reference architectures are also available, though some show no current maintenance.
3. Baseline before you set targets: Collect enough consistent data to establish a baseline before you act on it. Use the same rolling windows for every team, and inspect recovery-time percentiles alongside the median rather than relying on a mean alone.
4. Wire the stability metrics to your telemetry: Late detection or missing incident records will skew recovery time and change failure rate, which means mean time to detect and the coverage of your telemetry data both affect the result. Your analytics system can accept incident events from an inbound alert integration to feed those metrics automatically.

Definitions belong ahead of dashboards. When your team agrees on what counts as a deployment, you can correct a bad number quickly, and once measurements reflect the real lifecycle, you can connect delivery performance with faster service restoration.

From Tracking DORA Metrics to Restoring Service Faster

DORA metrics give your team a shared, evidence-based vocabulary for software delivery performance, but a dashboard only supports improvement when you connect its measurements to action. Moving from Low toward Elite performance depends on smaller batches, tighter feedback cycles, and faster detection and diagnosis when a deployment fails.

Faster diagnosis is where an AI observability platform like Coralogix pays back directly on failed deployment recovery time. Coralogix’s autonomous observability agent, Olly, runs AI root cause analysis across metrics, logs, and traces, then surfaces the root cause of a failed deployment without manual correlation. That shortens investigation while keeping the recovery data tied to the same telemetry your other DORA metrics rely on.

To see how that works with your production data, start a free 14-day Coralogix trial and point Olly at it

Frequently Asked Questions About DORA Metrics

What does DORA stand for?

DORA stands for DevOps Research and Assessment, the research program behind the State of DevOps Report series. The program publishes its annual reports and capability guides at dora.dev.

What are the four DORA metrics?

The four historical DORA metrics are deployment frequency, lead time for changes, change failure rate, and time to restore service. The current model calls their equivalents deployment frequency, change lead time, change fail rate, and failed deployment recovery time. Historically, the first two described delivery speed, while the second two covered failures and recovery; the current model groups failed deployment recovery time under Throughput.

What are the 5 DORA metrics?

The five metrics in DORA’s current model are change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. Deployment rework rate joined the model later and measures the share of deployments that were unplanned responses to production incidents. The model now treats reliability as an operational measure rather than one of the five delivery metrics.

What is the difference between Flow metrics and DORA metrics?

DORA metrics measure the delivery pipeline from code commit through production and recovery at the application or service level. Flow metrics come from Mik Kersten’s book Project to Product and track how work items (features, defects, risks, and debts) move through an entire product value stream. You can use DORA to stabilize the pipeline and add Flow metrics to connect that pipeline with business value.