What are the DORA metrics?

DORA metrics are four measures of software delivery performance: deployment frequency, lead time for changes, change failure rate, and time to restore service. They balance velocity against stability, giving engineering teams a shared language for performance. The framework comes from Google's DevOps Research and Assessment team and is the standard benchmark for comparing engineering health across organizations.

The four metrics

Deployment frequency measures how often your team releases to production. It captures throughput at the output level. Elite-performing teams deploy multiple times per day; low performers may deploy once per month or less.

Lead time for changes measures the time from code commit to that code running in production. A short lead time indicates a healthy, automated delivery pipeline. Elite teams achieve lead times under one hour; high performers typically fall between one day and one week.

Change failure rate (CFR) is the percentage of deployments that cause a failure requiring remediation, such as a rollback, hotfix, or incident. It is the primary stability signal on the delivery side. A high CFR indicates that changes are reaching production with undetected defects or risky configurations.

Time to restore service measures how long it takes to recover from a production failure. It is the primary stability signal on the operations side. Elite teams restore service in under one hour. This metric is often referred to as MTTR, mean time to restore or mean time to recovery.

Velocity vs. stability

Deployment frequency and lead time for changes measure throughput. Change failure rate and time to restore service measure stability. The central finding from DORA research is that elite teams do not trade one for the other: they score well on all four simultaneously.

This matters because the common assumption is that shipping faster means breaking more things. DORA data consistently shows the opposite. Teams with strong deployment pipelines, automated testing, and fast recovery mechanisms can move quickly precisely because they have invested in reliability. Stability is an enabler of speed, not a constraint on it.

Where most teams lose ground

CFR and MTTR are where the gap between elite and average teams is widest, and where the improvement leverage is highest.

Lowering CFR requires catching risky changes before they reach production: better automated testing, pre-deploy policy checks, and change risk signals. Lowering MTTR requires fast, accurate diagnosis once something does fail. The two are related: teams that can identify the true root cause of a failure quickly close incidents faster and build the institutional knowledge to prevent recurrence.

Root-cause identification is one of the hardest parts of incident response. NOFire AI's benchmark work, measuring against the RCAEval dataset (N=735, ACM 2025), found 89% Top-1 root-cause accuracy, compared to a 17-42% range for prior approaches. The methodological details are in the AI SRE Benchmark.

Elite vs. high performer tiers

DORA publishes performance tiers each year. The thresholds below reflect the commonly cited definitions:

Metric	Elite	High
Deployment frequency	On demand (multiple/day)	1/day to 1/week
Lead time for changes	Less than 1 hour	1 day to 1 week
Change failure rate	0-15%	16-30%
Time to restore service	Less than 1 hour	Less than 1 day

Medium and low performers sit below these thresholds. The gap between elite and low performers on time to restore is typically measured in hours vs. weeks.

Most teams tracking DORA start with deployment frequency because it is easy to instrument. CFR and MTTR require incident tracking and post-mortem discipline to measure accurately. Starting with all four together, even with rough initial numbers, gives a more useful baseline than optimizing one metric in isolation.

See the AI SRE Benchmark to go deeper on how automated root-cause analysis affects MTTR at scale.