Most engineering metrics are vanity metrics. Lines of code, story points, commit counts — they measure activity, not outcomes.
DORA metrics are different. They're the only engineering metrics with rigorous academic research proving their correlation to business outcomes. The DORA team at Google surveyed 32,000+ professionals across multiple years and proved that these four metrics predict both technical AND business performance.
The 4 DORA Metrics
1. Deployment Frequency
How often you deploy to production.
| Level | Frequency |
|---|---|
| Elite | Multiple per day |
| High | Daily to weekly |
| Medium | Weekly to monthly |
| Low | Monthly to biannual |
Elite teams deploy 973x more frequently than low performers.
2. Lead Time for Changes
Time from code commit to running in production.
| Level | Lead Time |
|---|---|
| Elite | < 1 hour |
| High | 1 day - 1 week |
| Medium | 1 week - 1 month |
| Low | 1 - 6 months |
Where time is typically lost: code review queues, manual QA, change advisory boards, deployment windows.
3. Change Failure Rate
Percentage of deployments causing failures in production.
| Level | Failure Rate |
|---|---|
| Elite | 0-5% |
| High | 5-10% |
| Medium | 10-15% |
| Low | 16-30%+ |
How to reduce it: automated testing, feature flags, canary deployments, better code review.
4. Mean Time to Recovery (MTTR)
How quickly you recover from a production incident.
| Level | Recovery Time |
|---|---|
| Elite | < 1 hour |
| High | < 1 day |
| Medium | 1 day - 1 week |
| Low | > 1 week |
Low MTTR requires: good monitoring, clear incident response, multiple people who can debug each system (bus factor matters here).
The Key Insight
Speed and stability are NOT tradeoffs.
This is the most important finding. Elite performers are both faster AND more reliable. The common belief that "moving fast breaks things" is a myth. Teams with better practices achieve both.
Why These 4 and Not Others?
The research shows teams with better DORA metrics also have:
- Higher organizational performance (profitability, market share)
- Lower employee burnout
- Higher job satisfaction
- Better ability to meet business goals
No other set of engineering metrics has this level of evidence behind it.
How to Measure Them
Manual surveys. Ask your team: How often did we deploy? How long from commit to prod? What % caused issues? How fast did we recover? Works for small teams starting out.
CI/CD pipeline data. GitHub Actions, GitLab CI, Jenkins already track deployment frequency and lead time.
Incident management data. PagerDuty, Opsgenie, incident.io track MTTR. Correlate with deployment timestamps for change failure rate.
Dedicated platforms. Sleuth, LinearB, Jellyfish, Swarmia aggregate from multiple sources automatically.
Codebase intelligence. Glue calculates engineering health metrics including code change velocity and team collaboration patterns that complement DORA metrics with deeper codebase insights.
Common Mistakes
Measuring adoption, not improvement. "80% of engineers use our CI/CD" is not a DORA metric. Measure outcomes.
Optimizing all four simultaneously. Start with deployment frequency. When you deploy small batches frequently, lead time drops, failures are easier to diagnose, and recovery is faster.
Gaming the metrics. Deploying empty commits, ignoring incidents. Use all four together and focus on trends rather than absolute numbers.
Treating DORA as DevOps-only. These measure the entire software delivery process. They're relevant to engineering leadership, product teams, and anyone who cares about how fast software reaches users.
Getting Started
- Pick ONE metric. Deployment frequency is the easiest to start with.
- Measure the baseline. Where are you today?
- Set a target. "Move from monthly to weekly deployments in Q2."
- Remove the biggest bottleneck. Usually it's batch size, testing, or approval processes.
- Measure monthly. Track trends, not snapshots.
Originally published on getglueapp.com/glossary/dora-metrics
Glue provides engineering intelligence that complements DORA metrics — mapping code health, knowledge silos, and team collaboration patterns.
Top comments (0)