DORA Metrics Explained: The 5 Software Delivery Metrics

DORA now defines five software delivery performance metrics, not the original four keys. They measure change throughput and deployment instability: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate.

This guide uses the current DORA definitions, updated in January 2026, and shows how to collect the five metrics without turning them into targets people game.

Where DORA Metrics Come From

DORA stands for DevOps Research and Assessment. Its metrics have changed as the research has evolved. The DORA metrics history explains two important updates: "time to restore service" became the narrower failed deployment recovery time in 2023, and deployment rework rate became a fifth metric in 2024.

The current model has two factors:

1. Throughput: change lead time, deployment frequency, and failed deployment recovery time.
2. Instability: change fail rate and deployment rework rate.

Track the five together. Deployment frequency without failure data rewards reckless shipping; a low failure rate without throughput can reward shipping nothing.

Metric 1: Deployment Frequency

Deployment frequency measures how often you successfully release to production. Elite teams deploy on demand — often multiple times per day — while lower performers deploy weekly, monthly, or less.

Why it matters: frequent, small deployments are safer, not riskier. A change set of ten lines is trivial to review, test, and roll back. A quarterly release bundling six months of work is a high-stakes event where any one of hundreds of changes can bring the system down, and bisecting the culprit is a nightmare.

How to measure it well:

• Count production deployments, not merges or builds. A deploy that never reaches users doesn't count.
• Track the trend, not a single number. Rising frequency with stable failure rate is the signal you want.
• Watch for batching — if frequency is low because changes pile up, that's a deployment risk waiting to happen.

Metric 2: Lead Time for Changes

Lead time for changes measures how long it takes a commit to reach production. It's the clock from "code committed" to "code running for users" — the latency of your delivery pipeline.

Short lead times mean fast feedback. A bug fix committed in the morning that's live by lunch lets you respond to incidents and customer needs in hours instead of weeks. Long lead times usually point to manual approval gates, flaky test suites, slow CI/CD pipelines, or heavyweight release processes.

How to measure it well:

• Measure from commit to production deploy, not from ticket creation — you're measuring the pipeline, not planning.
• Use a median or percentile, not an average, so one stalled change doesn't distort the picture.
• Break it down by stage (review, test, deploy) to find the actual bottleneck before you try to fix it.

Metric 3: Failed Deployment Recovery Time

Failed deployment recovery time is the time from a failed production deployment to recovery. It covers deployment-caused failures that require immediate intervention, rather than every operational incident.

That scope matters. A database hardware failure belongs in reliability reporting and MTTR, but it does not belong in this DORA metric unless a deployment caused it.

How to measure it well:

• Link the failed deployment, incident, first intervention, and recovery timestamps.
• Stop the clock when user-facing service is restored, even if the permanent fix follows later.
• Report a median and upper percentile as well as the mean; one long recovery can disappear inside an average.

Metric 4: Change Fail Rate

Change fail rate is the ratio of deployments that require immediate intervention. If 5 of 100 deployments need a rollback, hotfix, feature-flag reversal, or incident response, the rate is 5%.

Define "immediate intervention" before collecting data. Do not count every discovered defect, and do not quietly exclude a flag rollback simply because it avoided a redeploy.

How to measure it well:

• Use failed deployments / total production deployments × 100.
• Join incidents and rollback events to the deployment that caused them.
• Review ambiguous cases consistently so teams cannot improve the number by changing labels.

Metric 5: Deployment Rework Rate

Deployment rework rate is the ratio of unplanned deployments made to address a user-facing production bug. It captures reactive work that change fail rate can miss—for example, a bug discovered the next day that requires an unplanned fix but never triggered an immediate rollback.

Measure it as unplanned corrective deployments / total deployments × 100. Mark the corrective deployment itself as rework and link it to the originating defect or incident. Keep planned follow-up improvements out of the numerator.

How the Five Metrics Work Together

The reason DORA uses four metrics, not one, is that each pair guards against gaming the other:

Do not copy old "elite/high/medium/low" thresholds into permanent goals. DORA's benchmarks change by research period, and the latest Quick Check scores all five metrics against current benchmark data. Your more durable question is whether throughput improves without increasing instability.

How to Start Tracking DORA Metrics

You don't need a dedicated platform to begin:

• Deployment frequency and lead time come from your CI/CD system and version control — most pipelines already log deploy events and commit timestamps.
• Failed deployment recovery time comes from linking a failed deploy to the moment service is restored.
• Change fail rate comes from deployments that require immediate remediation.
• Deployment rework rate comes from unplanned corrective deployments tied to user-facing bugs.

Start with a spreadsheet if you have to. The discipline of consistently defining and recording the four events matters far more than the tooling. Once the definitions are stable, automating the collection is straightforward.

How Webalert Helps

DORA's recovery and instability metrics depend on detecting and attributing deployment failures accurately:

• Faster detection starts recovery sooner — Webalert checks the service from outside and catches user-visible deployment failures.
• Deploy-aware monitoring — correlate failures with releases so you can attribute them to a specific change and measure change failure rate accurately.
• Content validation, not just status codes, so a broken deploy that still returns 200 OK doesn't slip through as a success.
• Status pages and alerting to coordinate the response and stop the recovery clock as fast as possible.

Webalert does not compute all five DORA metrics. Version control, CI/CD, deployment records, and incident data remain the system of record; outside-in monitoring contributes failure and recovery evidence.

Summary

The current five DORA metrics are change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. Three contribute to throughput and two to instability.

You do not need a dedicated platform to start. Define the events consistently, link deployments to incidents and corrective work, and improve your own trend instead of optimizing for a stale benchmark label.

Catch failures faster, restore service sooner

Start monitoring with Webalert →

See features and pricing. No credit card required.