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
LevelFrequency
**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
LevelLead 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
LevelChange 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
LevelMTTR (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 source repositories and delivery pipelines to calculate all 4 DORA metrics automatically, with Elite/High/Medium/Low benchmarks. Free plan covers up to 5 repositories.
Top comments (0)