In 2023, Google's State of DevOps report revealed that "Elite" engineering teams deploy 208 times more frequently than Low performers, and restore services 2,604 times faster after incidents. That's not magic — it's the result of measuring the right things.

DORA metrics are now the industry standard for evaluating software delivery performance. This guide explains what they are, how to calculate them, and — most importantly — how to use them to drive continuous improvement in your team.

What Are DORA Metrics?

DORA stands for DevOps Research and Assessment, a research program launched by Google in 2014 to identify what separates high-performing engineering teams from the rest. After analyzing tens of thousands of teams worldwide, researchers converged on 4 metrics that predict both technical performance and business outcomes.

These metrics measure two complementary dimensions:

Velocity: how fast the team delivers value (Deployment Frequency + Lead Time)
Stability: how reliable that delivery is (Change Failure Rate + MTTR)

The core insight is counter-intuitive at first: speed and stability are not opposites. The best teams excel on all four metrics simultaneously.

The 4 DORA Metrics in Detail

1. Deployment Frequency

Definition: How often your team successfully deploys code to production.

Formula: Deployment Frequency = Total deployments / Number of days

Level	Frequency
Elite	Multiple times per day
High	Once a week to once a month
Medium	Once a month to once every 6 months
Low	Less than once every 6 months

Deploying rarely is not a sign of caution. It is usually a symptom of overly manual processes or bloated release cycles.

2. Lead Time for Changes

Definition: Time between the first commit of a change and its successful deployment to production.

Formula: Lead Time = Deployment timestamp - First commit timestamp

Level	Lead Time (median)
Elite	Less than 24 hours
High	Less than one week
Medium	One week to one month
Low	One to six months

If your p90 is 10x your median, something is blocking changes. Look for long-open PRs or manual approval gates.

3. Change Failure Rate

Definition: Percentage of deployments that cause a production degradation (rollback, hotfix, emergency patch).

Formula: CFR = (Failed deployments / Total deployments) × 100

Level	Change Failure Rate
Elite	0–5%
High	5–10%
Medium	10–15%
Low	>15%

A 0% rate is not necessarily good — it may mean the team is taking no risks. The goal is to stay under 5% while deploying frequently.

4. Mean Time to Recovery (MTTR)

Definition: Average time to restore service after a production incident.

Formula: MTTR = Total recovery time / Number of incidents

Level	MTTR (median)
Elite	Less than 1 hour
High	Less than 24 hours
Medium	1 day to 1 week
Low	More than 1 week

One hour of downtime on a B2B SaaS can represent tens of thousands of dollars in lost customer trust. MTTR is directly tied to revenue.

Why Measure DORA Metrics?

They predict organizational performance. Elite teams deploy 208x more frequently, have 7x fewer failed changes, and achieve 127x shorter lead times compared to Low performers.
They reveal bottlenecks. High lead time with low deployment frequency often points to heavy approval processes. A high CFR signals inadequate test coverage.
They are objective. Unlike subjective performance reviews, DORA metrics come directly from Git activity and CI/CD pipelines.

How to Improve Each Metric

Deployment Frequency

Reduce change size (PRs under 400 lines)
Automate your CI/CD pipeline
Use feature flags to decouple deployment from release
Remove approval gates that add no value

Lead Time

Define a code review SLA (every PR reviewed within 24h)
Parallelize CI tests to reduce pipeline duration
Break large PRs into smaller, independently deployable changes

Change Failure Rate

Increase test coverage on critical paths (target: 80%+)
Strengthen code reviews for high-risk changes
Adopt canary releases or blue/green deployments

MTTR

Improve observability (structured logs, metrics, calibrated alerts)
Automate rollbacks on failed health checks
Write incident runbooks before you need them

Attack one metric at a time. Start with Deployment Frequency — it is often the easiest to improve and creates a flywheel effect on the others.

90-Day Improvement Plan: From Medium to High

Month 1 — Baseline and quick wins

Measure all 4 metrics over the last 90 days
Automate the deployment pipeline
Introduce a PR size rule (max 400 lines)

Month 2 — Systematic improvement

Establish a code review SLA (24h)
Add automated tests on critical paths
Set up basic observability alerts

Month 3 — Consolidation

Roll out feature flags for new features
Document key incident runbooks
Re-measure and compare against your initial baseline

Conclusion

DORA metrics are not an end in themselves. They are diagnostic tools that help you answer one fundamental question: is the way we deliver software getting better or worse?

Teams that measure these indicators regularly make better decisions about process investments, justify technical choices more easily, and catch systemic problems before they become crises. Measurement alone does not transform your team — but it creates the visibility without which no lasting improvement is possible.

DevLyTicks connects to your GitHub repositories and calculates all 4 DORA metrics automatically, with Elite/High/Medium/Low benchmarks. Free plan covers up to 5 repositories.

DORA Metrics: The Complete Guide for Engineering Teams (2026)