DORA Metrics: The Complete Guide
Everything you need to understand, implement, and act on the four metrics that actually predict software delivery performance.
What is DORA?
DORA (DevOps Research and Assessment) is a research program that started at Google and spent years studying what makes high-performing software teams actually perform. They surveyed over 32,000 professionals worldwide and identified four key metrics that predict organizational performance.
The genius of DORA is that it's evidence-based. These aren't vanity metrics or someone's opinion about what matters—they're statistically validated predictors of success. Teams that excel on these metrics ship faster, have fewer outages, and recover from incidents more quickly.
Key Insight:
DORA metrics measure outcomes, not activities. They don't care how many hours you work or how many meetings you attend—they care about how quickly you can deliver value and how reliably your systems run.
Why DORA Metrics Matter
They Predict Business Performance
DORA's research shows that high performers are 2x more likely to exceed organizational performance goals. This isn't just about engineering—it affects revenue, customer satisfaction, and market share.
They're Leading Indicators
Most metrics tell you what happened. DORA metrics tell you what's about to happen. Degrading DORA scores predict future incidents, burnout, and attrition before they become visible.
They Drive the Right Behaviors
Unlike "lines of code" or "story points completed," DORA metrics encourage practices that actually matter: automation, small batches, fast feedback loops, and learning from failure.
The Four Metrics
1. Deployment Frequency
How often do you deploy code to production or release to end users?
This measures your team's ability to deliver value frequently. Elite performers deploy multiple times per day. This isn't about rushing—it's about having systems and culture that make small, safe deployments routine.
Why It Matters:
- • Faster feedback from users and systems
- • Smaller changes = lower risk per deployment
- • Reduces batch size and work-in-progress
- • Enables experimentation and rapid iteration
Common Misconception:
"We deploy every sprint, so we're good." Sprints are arbitrary time boxes. Elite teams deploy when code is ready—which might be multiple times per day.
2. Lead Time for Changes
How long does it take to go from code committed to code running in production?
This is your system's metabolism—how quickly you can respond to opportunities or threats. Elite teams have lead times of less than one hour. That sounds impossible until you see it in action.
What Slows Lead Time:
- • Manual approval gates and change boards
- • Slow, brittle test suites that developers don't trust
- • Merge conflicts from large, long-lived feature branches
- • Manual deployment processes and environment setup
Pro Tip:
Measure lead time from first commit to production deploy, not from ticket creation. You want to measure technical throughput, not project management overhead.
3. Change Failure Rate
What percentage of changes to production result in degraded service or require remediation?
This is your quality indicator. It balances speed with stability. Elite performers keep this below 15%—meaning 85%+ of their deployments go smoothly. This seems high until you realize they're deploying hundreds of times more often.
What Counts as a Failure:
- ✓ Deployment causes service degradation or outage
- ✓ Requires a hotfix or immediate rollback
- ✓ Results in customer-impacting bugs
- ✗ Minor bugs fixed in the next regular deploy (not a failure)
Critical Point:
0% failure rate is the wrong goal. It means you're not taking enough risks or deploying often enough. Elite teams accept some failures as the cost of moving fast.
4. Time to Restore Service
How long does it take to restore service when an incident occurs?
Also called Mean Time to Recovery (MTTR), this measures your resilience. Elite teams restore service in less than one hour. This isn't about having fewer incidents—it's about recovering from them quickly.
What Enables Fast Recovery:
- • Automated rollback and deployment capabilities
- • Good monitoring and observability to diagnose issues
- • Practiced incident response processes
- • Architectural patterns like feature flags and circuit breakers
Reality Check:
If your recovery process involves scheduling an emergency change board meeting, you're not recovering—you're introducing more delay while your customers suffer.
Performance Benchmarks
DORA research categorizes teams into four performance levels. Here's what each looks like:
| Metric | Elite | High | Medium | Low |
|---|---|---|---|---|
| Deployment Frequency | On-demand (multiple per day) | Between once per day and once per week | Between once per week and once per month | Fewer than once per month |
| Lead Time | Less than one hour | Between one day and one week | Between one week and one month | More than one month |
| Change Failure Rate | 0-15% | 16-30% | 31-45% | 46-60% |
| Time to Restore | Less than one hour | Less than one day | Between one day and one week | More than one week |
Important Note:
These categories aren't rigid tiers—they're continuous distributions. A team deploying once per day isn't "worse" than one deploying twice per day. Focus on trends and improvement, not chasing labels.
How to Actually Measure DORA Metrics
You don't need expensive tools or complex instrumentation. Here's how to start:
1. Start with Your CI/CD System
Most of what you need is already in your deployment pipeline:
- • Deployment Frequency: Count successful production deployments per day/week
- • Lead Time: Timestamp from first commit to production deploy completion
gh api repos/org/repo/deployments --jq '.[] | select(.environment=="production")'
2. Use Your Incident Management System
If you use PagerDuty, Opsgenie, or similar:
- • Change Failure Rate: Tag incidents caused by recent deploys
- • Time to Restore: Time from incident creation to resolution
Pro tip: Add a "caused-by-deployment" tag to incidents during postmortems. This makes CFR calculation trivial.
3. Use Existing Tools (Free Options)
- Sleuth - Connects to GitHub, Jira, PagerDuty for free tier
- Haystack - Open-source DORA metrics dashboard
- LinearB - Free tier for small teams
- DIY Spreadsheet - Seriously, start simple and manual if needed
Don't Let Perfect Be the Enemy of Good
Start by tracking these metrics manually in a spreadsheet for 2-4 weeks. You'll learn what data you actually have access to and what gaps need to be filled. Automate later.
Common Mistakes (And How to Avoid Them)
❌ Gaming the Metrics
The trap: Teams deploy trivial changes multiple times per day to boost deployment frequency, or mark incidents as "non-critical" to improve CFR.
The fix: Make metrics team-owned, not manager-owned. Use them for learning and improvement, not performance reviews. If people are gaming them, you've created the wrong incentive structure.
❌ Measuring Without Acting
The trap: You set up dashboards, track metrics religiously, but nothing changes because no one uses the data to drive decisions.
The fix: Every metric review should end with "What are we going to change based on this?" If the answer is "nothing," stop measuring.
❌ Comparing Teams
The trap: "Why is Team A deploying 3x per day while Team B only deploys once per week? Team B must be underperforming."
The fix: Different systems have different constraints. A team managing embedded firmware can't deploy like a web app team. Compare teams to themselves over time, not to each other.
❌ Ignoring the "Why"
The trap: "Our lead time increased from 2 hours to 4 hours." Okay, but why? Was it test suite changes? Infrastructure issues? Organizational changes?
The fix: When metrics change, dig into the qualitative reasons. Talk to engineers. Look at recent changes to process, tooling, or team structure.
❌ Optimizing Only One Metric
The trap: "We need to deploy more often!" So you skip testing and change failure rate skyrockets.
The fix: DORA metrics are a system. They balance speed with stability. Elite teams are good at ALL FOUR, not just one or two.
Getting Started: Your First 30 Days
Week 1: Baseline
- → Manually track deployments for one week. How many? What time of day?
- → Pick 3-5 recent deployments and calculate lead time from commit to production
- → Review recent incidents—how many were caused by deployments?
Week 2: Instrument
- → Set up basic tracking (spreadsheet or simple tool)
- → Add timestamps to your deployment pipeline if missing
- → Create incident tagging process for deployment-related issues
Week 3: Share
- → Present baseline metrics to the team (no judgment, just data)
- → Ask: "What surprises you? What doesn't?"
- → Identify the biggest bottleneck or pain point
Week 4: Act
- → Pick ONE metric to improve this quarter
- → Run an experiment or make one change
- → Set up weekly check-ins to review progress
How to Improve Your DORA Metrics
Improving Deployment Frequency
- ↗ Automate everything. If a human is clicking buttons to deploy, that's your bottleneck. Full CI/CD automation is non-negotiable.
- ↗ Shrink batch size. Break large features into smaller, independently deployable chunks. Use feature flags to deploy code that isn't "done" yet.
- ↗ Remove approval gates. If you trust your tests and monitoring, you don't need manual approvals. If you don't trust them, fix that first.
Improving Lead Time
- ↗ Speed up your build. If CI takes 30+ minutes, developers will batch changes and wait. Target under 10 minutes for fast feedback.
- ↗ Trunk-based development. Short-lived branches (< 1 day) reduce merge conflicts and integration time. Use feature flags for incomplete work.
- ↗ Simplify environments. If spinning up a staging environment takes hours, that's part of your lead time. Containerize, use IaC, make it instant.
Reducing Change Failure Rate
- ↘ Invest in test coverage. Not just any tests—fast, reliable tests that catch real issues. Focus on integration tests over unit tests for better ROI.
- ↘ Better observability. You can't catch issues before they hit production if you can't see what's happening. Logs, metrics, traces—all of it.
- ↘ Progressive rollouts. Deploy to 1% of traffic first, then 10%, then 100%. Catch issues before they affect everyone.
Reducing Time to Restore
- ↘ One-click rollback. This should be the easiest thing in the world. If it's not, fix that immediately—it's your safety net.
- ↘ Practice incident response. Run game days and chaos engineering exercises. You get good at what you practice.
- ↘ Architectural patterns. Circuit breakers, graceful degradation, retry logic—build resilience into the system, not just the process.
The Key Insight:
Elite teams don't optimize these metrics individually—they build systems that improve all four simultaneously. Automation, small batches, fast feedback loops, and good testing practices improve EVERYTHING at once.
The Bottom Line
DORA metrics aren't just numbers on a dashboard. They're a lens for understanding how your organization builds and ships software. They tell you where friction exists, where trust is broken, and where small changes can have outsized impact.
Start measuring. Start improving. And remember: the goal isn't to hit "elite" performance by next quarter. The goal is to build a culture of continuous improvement where engineers feel empowered to make things better every single day.
That's what great teams do. And that's what DORA metrics help you build.
Need Help Implementing DORA Metrics?
I work with teams to set up measurement, identify bottlenecks, and build roadmaps for improvement. Let's talk about your specific situation.
Get in Touch