DORA metrics are four measures of software delivery performance: deployment frequency, lead time for changes, change failure rate, and time to restore service. They come from DORA — the DevOps Research and Assessment program — and the first two describe how quickly a team ships, while the second two describe how safely. Taken together they give you a picture of delivery performance that neither speed nor stability gives on its own.
That is the short answer. The rest of this guide is about the part nobody warns you about: defining, measuring and actually acting on them.
#What are DORA metrics?
DORA metrics are the four measures that the DevOps Research and Assessment program identified as indicators of software delivery performance, published each year in the State of DevOps report and popularised by the book Accelerate.
Here is what each one measures.
Deployment frequency — how often your team successfully releases to production. Counted as a rate: deploys per day, per week, or per month, depending on where your team is.
Lead time for changes — how long it takes a commit to reach production. It starts when code is committed and ends when it is running for users. It is a delivery measure, not an estimation measure: it says nothing about how long the work took to design or write.
Change failure rate — the percentage of deployments to production that cause a degraded service and require a fix, a rollback, or a patch. It is a rate, not a count, so it stays meaningful as you deploy more often.
Time to restore service — how long it takes to recover when a change does break production. DORA's more recent reports call this failed deployment recovery time; older material and most tooling still call it mean time to recovery, or MTTR.
Two of these are speed measures and two are stability measures, and that pairing is the point. A team can push deployment frequency up by skipping review, but the change failure rate will show it. A team can drive change failure rate to near zero by shipping once a quarter, but the lead time will show that. Read alone, any one of the four is easy to game. Read together, they are hard to fake.
Later DORA research also examines reliability as a measure of operational performance, but when people say "the DORA metrics" they mean the four above.
#Why DORA metrics matter
Ask most engineering leaders how their team is performing and you get "pretty good" or "faster than last quarter". Ask how often they deploy, how long a commit takes to reach production, how many deploys go wrong and how long recovery takes, and most cannot answer without guessing. Teams track story points and burndown charts and miss the four numbers that describe delivery itself.
The reason those four matter is batch size. A team that deploys once a month pushes weeks of changes at once, and every deploy is frightening because so much can go wrong. When something does break, it is hard to tell which of dozens of changes caused it, and the investigation eats time that could have gone into building. A team that deploys daily ships small changes, each one less risky, and finds out sooner when something is wrong.
Lead time works the same way. It is not coding time. It is the whole pipeline: review, testing, approval and deployment. Elite teams get from commit to production inside a day because they have automated what can be automated and made deploys boring. Teams that take a week or more are usually waiting rather than working — on manual approvals, slow test suites, or a weekly deployment window kept "for safety".
The research behind DORA ties these measures to outcomes beyond engineering. The State of DevOps reports have consistently found that high performers are around twice as likely to meet or exceed their organisational goals for profitability, productivity and market share, and the 2014 report linked high IT performance to faster market capitalisation growth among public companies. The same research has linked strong delivery performance to lower burnout. The gap at the bottom is wide too: in the 2018 and 2019 reports, low performers had change failure rates of 46–60%, against 0–15% for the elite cluster.
#Why measuring them is harder than defining them
I remember the first time I tried to implement DORA metrics for my engineering team. We had all the theory down—we'd read the research, understood why these metrics mattered, and were convinced they'd help us improve.
Then we actually tried to measure them.
Our deployment frequency was easy enough to track, but what counted as a "deployment"? Did hotfixes count? What about configuration changes? Lead time seemed straightforward until we realized we had no consistent way to mark when work actually started.
Three months later, we had spreadsheets full of inconsistent data that told us nothing useful about our actual performance.
That's the thing about DORA metrics—the concepts are simple, but implementation is where most teams struggle. You need the right tools, the right processes, and most importantly, the right approach to make these metrics actually improve your team's performance instead of just creating measurement overhead.
This guide covers everything I've learned about successfully implementing DORA metrics across different teams, from startups to large enterprises. We'll walk through practical frameworks, tool recommendations, common pitfalls, and proven strategies that actually work in the real world.
#The DORA Framework: Beyond Basic Measurement
DORA metrics aren't just numbers to track—they're a comprehensive framework for understanding and improving software delivery performance. Let's establish what world-class performance looks like:
#Elite Performer Benchmarks
DORA's State of DevOps research groups teams into performance clusters — commonly elite, high, medium and low — based on where they land across the four metrics. The figures below are the shape of the elite cluster as DORA has described it. Treat them as direction, not as a target to hit: the cluster boundaries are recalculated from each year's respondents, so they move, and the report you are quoting matters.
Deployment Frequency: Multiple deployments per day
- Teams shipping features as soon as they're ready
- Automated deployment pipelines with minimal manual intervention
- Feature flags enabling safe, frequent releases
- Clear separation between deployment and release
Lead Time for Changes: Less than one day
- From commit to production deployment
- Streamlined code review and testing processes
- Automated quality gates and fast feedback loops
- Efficient branching strategies and integration practices
Change Failure Rate: 0-15%
- Less than 15% of deployments cause service impairment
- Robust testing strategies catching issues early
- Monitoring and alerting systems providing rapid detection
- Rollback capabilities and deployment safety measures
Mean Time to Recovery: Less than one hour
- Rapid incident detection and response procedures
- Automated rollback and recovery capabilities
- Clear escalation paths and on-call processes
- Post-incident learning and improvement cycles
#Implementation Framework: The DORA Adoption Journey
#Phase 1: Foundation Setting (Weeks 1-4)
Week 1: Assessment and Tool Audit
Start by understanding your current state. Most teams think they know their deployment frequency or lead time, but the numbers often surprise them.
Audit your existing tools:
- Version control systems (GitHub, GitLab, Bitbucket)
- CI/CD platforms (Jenkins, GitHub Actions, CircleCI)
- Deployment tools (Kubernetes, Docker, cloud platforms)
- Monitoring and alerting systems (Grafana, DataDog, New Relic)
- Project management tools (Jira, Linear, Notion)
Week 2: Data Source Integration
Identify where your DORA metric data lives:
- Deployment logs and CI/CD pipeline history
- Version control commit and merge data
- Incident management system records
- Production monitoring and error tracking
- Support ticket and bug report systems
Week 3: Baseline Measurement Setup
Implement basic measurement for each metric:
- Define what constitutes a "deployment" for your team
- Establish lead time measurement points (commit to production)
- Categorize what qualifies as a "change failure"
- Set up incident detection and timing procedures
Week 4: Initial Data Collection
Start collecting baseline data without making any process changes. This gives you a true picture of your current performance and helps identify the biggest improvement opportunities.
#Phase 2: Measurement Standardization (Weeks 5-8)
Data Quality and Consistency
The biggest challenge in DORA implementation isn't technical—it's definitional. Teams waste months arguing about what counts as a deployment or when lead time starts.
Establish clear definitions:
Deployment Definition Framework:
- Production Deployments: Code changes reaching end users
- Hotfixes: Emergency fixes deployed outside normal process
- Configuration Changes: Production environment modifications
- Rollbacks: Reverting to previous application versions
- Database Migrations: Schema or data changes
Lead Time Measurement Points:
- Start Point: First commit on feature branch OR when work moves to "In Progress"
- End Point: Code successfully deployed to production OR when feature is available to users
- Exclusions: Time spent waiting for external dependencies, blocked work, or out-of-scope delays
Change Failure Classification:
- Service Degradation: Performance impact affecting user experience
- Service Outage: Complete service unavailability or critical functionality loss
- Security Issues: Vulnerabilities or data exposure requiring immediate attention
- Data Corruption: Incorrect data processing or storage problems
- Rollback Requirement: Any deployment requiring immediate reversal
#Phase 3: Process Integration (Weeks 9-16)
Embedding DORA into Development Workflow
The goal isn't just to measure—it's to make these metrics part of how your team thinks about and improves their work.
Daily Integration Strategies:
- Include DORA trends in daily standups
- Use lead time data for sprint planning and estimation
- Review deployment frequency patterns during retrospectives
- Analyze change failure patterns to identify improvement areas
Team Communication Framework:
- Weekly DORA metric reviews with trend analysis
- Monthly deep-dive sessions on improvement opportunities
- Quarterly benchmarking against industry standards
- Semi-annual process optimization based on metric insights
#Tool Implementation Guide
#Comprehensive DORA Measurement Stack
Option 1: GitHub-Centric Stack
1# Recommended for teams primarily using GitHub
2Version Control: GitHub
3CI/CD: GitHub Actions
4Deployment: GitHub Deployments API
5Monitoring: GitHub Insights + Custom dashboards
6DORA Platform: Coderbuds, LinearB, or Haystack
Option 2: GitLab Integrated Solution
1# Comprehensive GitLab-based measurement
2Platform: GitLab Ultimate
3DORA Metrics: Built-in GitLab DORA analytics
4CI/CD: GitLab CI/CD
5Monitoring: GitLab monitoring + external APM
6Incident Management: GitLab issues + PagerDuty
Option 3: Multi-Platform Enterprise Stack
1# For complex, multi-tool environments
2Version Control: GitHub Enterprise / GitLab / Bitbucket
3CI/CD: Jenkins / TeamCity / Azure DevOps
4Deployment: Kubernetes / Cloud platforms
5Monitoring: Grafana + Prometheus / DataDog / New Relic
6DORA Platform: Sleuth / Jellyfish / Code Climate Velocity
#Data Integration Patterns
API-First Integration: Most DORA implementations require connecting multiple data sources. Use APIs wherever possible to avoid manual data entry and ensure real-time accuracy.
1# Example: GitHub API integration for deployment frequency
2import requests
3from datetime import datetime, timedelta
4
5def get_deployment_frequency(repo, days=30):
6 """Calculate deployments per day over specified period"""
7 end_date = datetime.now()
8 start_date = end_date - timedelta(days=days)
9
10 deployments = github_api.get_deployments(
11 repo=repo,
12 start_date=start_date.isoformat(),
13 end_date=end_date.isoformat()
14 )
15
16 return len(deployments) / days
Webhook-Based Real-Time Updates: Set up webhooks to update DORA metrics in real-time as events occur:
1{
2 "event_type": "deployment",
3 "timestamp": "2025-08-21T10:30:00Z",
4 "environment": "production",
5 "commit_sha": "abc123def456",
6 "deployment_id": "deploy-789",
7 "status": "success"
8}
#Step 3: Create Measurement Dashboards
Build dashboards that show:
- Real-time DORA metrics for your team
- Trends over time (weekly, monthly, quarterly)
- Comparisons between different teams or projects
- Correlation between metrics (e.g., deployment frequency vs. failure rate)
#Step 4: Establish Team Processes
Weekly Reviews:
- Review DORA metrics with the team
- Identify bottlenecks and improvement opportunities
- Celebrate improvements and wins
- Plan specific actions for the following week
Monthly Analysis:
- Compare performance to industry benchmarks
- Analyze trends and seasonal patterns
- Identify systemic issues requiring larger changes
- Set improvement goals for the following month
#Common Implementation Challenges
#Challenge 1: Defining "Deployment"
Problem: Teams often struggle with what counts as a deployment, especially with microservices or feature flags.
Solution:
- Be consistent in your definition across teams
- Focus on when code changes become available to users
- Consider feature flag activations as deployments if they expose new functionality
#Challenge 2: Measuring Lead Time Accurately
Problem: Determining the start and end points for lead time measurement.
Solution:
- Start measuring from first commit on a feature branch
- End measurement when code is deployed and validated in production
- Use automation to track these events consistently
#Challenge 3: Attribution of Incidents
Problem: Determining which deployments caused which incidents.
Solution:
- Implement correlation tools that link deployments to incidents
- Use deployment markers in your monitoring systems
- Create clear processes for incident investigation and root cause analysis
#Challenge 4: Cultural Resistance
Problem: Teams may resist measurement, fearing blame or micromanagement.
Solution:
- Focus on team improvement, not individual performance
- Use metrics to identify systemic issues, not blame individuals
- Celebrate improvements and learning from failures
- Make the data transparent and accessible to the whole team
#DORA Metrics Best Practices
#1. Start Small
Begin with one or two metrics and expand gradually. Choose metrics that align with your current improvement focus.
#2. Automate Measurement
Manual metric collection is error-prone and time-consuming. Invest in automation early.
#3. Focus on Trends, Not Absolutes
Look for improvement trends rather than comparing absolute numbers to industry benchmarks initially.
#4. Combine with Other Metrics
DORA metrics are powerful but not comprehensive. Combine them with code quality metrics, team satisfaction scores, and business outcomes.
#5. Regular Review and Action
Metrics without action are just interesting numbers. Establish regular review cycles and improvement processes.
#6. Read Them in Context
The same number means different things for a five-person team shipping a web app and a fifty-person team shipping firmware. Consider team size, domain complexity and organisational constraints before comparing anyone to a benchmark — and aim for steady improvement rather than a perfect score, because a team chasing the elite cluster for its own sake will find ways to move the number that do not move the delivery.
#Advanced DORA Metrics Implementation
#Segmentation and Analysis
By Team: Compare metrics across different engineering teams to identify high-performing practices.
By Service: Track metrics per microservice or application to understand system-level performance.
By Feature Type: Separate bug fixes from new features to understand different types of work.
#Predictive Analytics
Use historical DORA metrics data to:
- Predict likely deployment success based on change characteristics
- Identify teams at risk for incidents based on recent metric trends
- Forecast capacity and timeline for upcoming features
#Integration with Business Metrics
Connect DORA metrics to business outcomes:
- Correlate deployment frequency with feature delivery velocity
- Link MTTR to customer satisfaction scores
- Analyze change failure rate impact on user engagement
#Tools and Resources
#Measurement Platforms
- Coderbuds: Specialized in PR and deployment metrics for engineering teams
- LinearB: Engineering metrics and insights platform
- Jellyfish: Engineering management and business-alignment reporting
- Haystack: Delivery bottleneck and cycle time analytics
- Swarmia: Developer productivity and working-agreement tooling
- Hivel: DORA and SPACE metrics with Jira investment reporting
- Waydev: Git analytics and developer activity reporting, built for large enterprises
- Sleuth: Deployment tracking and DORA metrics
- Pluralsight Flow (formerly GitPrime): Developer analytics, retiring at the end of 2027
#Open Source Solutions
- Backstage: Developer portal with metrics plugins
- Prometheus: Metrics collection and alerting
- Grafana: Visualization and dashboards
- Four Keys: Google's open-source DORA metrics implementation
#Getting Started Today
- Week 1: Install measurement tools and establish baseline
- Week 2: Create basic dashboards and begin data collection
- Week 3: Conduct first team review and identify improvement opportunities
- Week 4: Implement first process improvements and measure impact
#Frequently asked questions
#What are the four DORA metrics?
Deployment frequency, lead time for changes, change failure rate, and time to restore service. The first two measure speed, the second two measure stability, and the framework is built on reading them as a set rather than individually.
#What does DORA stand for?
DevOps Research and Assessment. It is the name of the research program, not of the metrics themselves — "DORA metrics" is shorthand the industry settled on for the four measures the program identified.
#Who created DORA metrics?
The DORA research program was founded by Nicole Forsgren, Jez Humble and Gene Kim, who published its findings in the annual State of DevOps reports and in the 2018 book Accelerate. Google acquired DORA in 2018, and the research has continued under Google Cloud since.
#How are DORA metrics measured?
Two different ways, and the distinction matters. DORA's own research is survey-based: teams self-report where they sit, which is why the published performance clusters are bands rather than precise thresholds. Tools that put a DORA dashboard in front of you derive the same four measures from system data instead — deploys from your CI/CD pipeline or deployment API, lead time from commit and merge timestamps, change failure rate from incidents correlated back to deployments, and recovery time from incident open and close times.
#Is MTTR still one of the DORA metrics?
Yes, under a different name. DORA's more recent reports use failed deployment recovery time, which is narrower and more precise: it measures recovery from a bad deployment specifically, rather than from any incident whatsoever. Most tooling and most teams still say MTTR. If you are comparing numbers between two sources, check which definition each one is using.
#Are DORA metrics used to measure individual developers?
No, and using them that way breaks them. All four are properties of a delivery system — pipelines, review practices, test coverage, on-call process — not of a person. Attribute a change failure rate to an individual and you will get fewer deploys, not fewer failures.
#What is a good deployment frequency?
The honest answer is "more often than last quarter". DORA's elite cluster deploys on demand, multiple times a day, but a team going from monthly to weekly has improved more meaningfully than a team going from twelve deploys a day to fifteen. Trend beats benchmark, especially in your first year of measuring.
#Do DORA metrics still work when AI is writing the code?
The four measures still hold, because they measure delivery rather than authorship. What changes is where the bottleneck sits. When code is generated faster, the constraint tends to move downstream into review, verification and deployment — which shows up as lead time and change failure rate rather than as anything you would see in commit volume.
#Conclusion
DORA metrics provide a proven framework for understanding and improving your engineering team's performance. By measuring deployment frequency, lead time for changes, mean time to recovery, and change failure rate, you can identify bottlenecks, celebrate improvements, and make data-driven decisions about your development process.
The key to success is starting simple, measuring consistently, and taking action based on your findings. Teams that implement DORA metrics consistently see significant improvements in both delivery speed and quality.
Ready to start measuring your team's software delivery performance? Try Coderbuds for automated DORA metrics tracking and engineering team insights.
#Sources and further reading
DORA metrics come from research by the DevOps Research and Assessment program, now part of Google Cloud, built on surveys of tens of thousands of professionals since 2014.
- DORA — the official home of the research, the metric definitions and the quick check
- State of DevOps reports — the annual reports the performance clusters are drawn from
- Accelerate: The Science of Lean Software and DevOps — Nicole Forsgren, Jez Humble and Gene Kim, 2018
This guide is the overview. Each metric has its own deep dive, starting with deployment frequency. For more on the practices that move these numbers, see code review best practices and measuring team performance.
#Related Reading
- Deployment Frequency - How often a team should actually ship
- Lead Time for Changes - Commit to production, and where it goes
- Change Failure Rate - Shipping faster without breaking more
- Mean Time to Recovery - What happens after it breaks
- SPACE Framework vs DORA Metrics - What DORA leaves out
- Understanding Performance Tiers - Reading elite, high, medium and low honestly
- Measuring Team Performance Beyond Lines of Code - Metrics that survive contact with people
- Engineering Metrics Maturity Model - What to measure at your stage
