DORA (DevOps Research and Assessment) metrics are the gold standard for measuring software delivery performance.

Based on years of research involving thousands of teams, these four key metrics provide objective insights into your DevOps capabilities and help identify areas for improvement.

This awesome image on the cover is generated by AI model Flux 1 dev.

What Are DORA Metrics?

The DORA research program, started by Nicole Forsgren, Jez Humble, and Gene Kim, has been studying DevOps practices since 2014. Through the “Accelerate State of DevOps Report,” they’ve identified four key metrics that predict software delivery performance:

1. Deployment Frequency - How often code is deployed to production
2. Lead Time for Changes - Time from code commit to production deployment
3. Change Failure Rate - Percentage of deployments that result in failures
4. Time to Restore Service - How quickly teams recover from incidents

These metrics are strongly correlated with organizational performance, team satisfaction, and business outcomes. Elite performers in these metrics show 50% higher market capitalization growth and 2.5x faster time to market.

The Four Key Metrics Explained

1. Deployment Frequency

Definition: How often your organization successfully releases code to production.

Why It Matters: Frequent deployments indicate mature CI/CD practices, smaller batch sizes, and reduced risk. Teams that deploy more often fix issues faster and deliver value to customers sooner.

Measurement Levels:

• Elite: Multiple deployments per day
• High: Once per day to once per week
• Medium: Once per month to once per six months
• Low: Fewer than once per six months

How to Track:

# Example: Count deployments in the last 30 days
# Using Git tags or deployment logs
git log --since="30 days ago" --oneline | grep -i deploy | wc -l

# Or query your CI/CD system
# Jenkins, GitLab CI, GitHub Actions, etc.

When tracking deployments with Git, refer to our GIT commands cheatsheet for comprehensive Git operations needed for version control and deployment tracking.

Improving Deployment Frequency:

• Implement automated CI/CD pipelines (see our GitHub Actions Cheatsheet for CI/CD automation examples)
• Reduce deployment batch sizes
• Practice trunk-based development (compare with Gitflow branching model to understand different branching strategies)
• Automate testing and quality checks
• Use feature flags for safer deployments

2. Lead Time for Changes

Definition: The time from when code is committed to version control until it’s successfully running in production.

Why It Matters: Shorter lead times mean faster feedback loops, quicker bug fixes, and more responsive delivery. This metric reflects the efficiency of your entire software delivery pipeline.

Measurement Levels:

• Elite: Less than one hour
• High: One day to one week
• Medium: One month to six months
• Low: More than six months

How to Track:

# Calculate lead time for a specific commit
# Get commit timestamp
COMMIT_TIME=$(git log -1 --format=%ct <commit-hash>)

# Get deployment timestamp (from your deployment system)
DEPLOY_TIME=$(<deployment-timestamp>)

# Calculate difference
LEAD_TIME=$((DEPLOY_TIME - COMMIT_TIME))

# Or use tools like:
# - GitHub Actions API
# - GitLab CI/CD metrics
# - Jenkins build timestamps

Improving Lead Time:

• Optimize CI/CD pipeline speed
• Parallelize test execution
• Reduce manual approval gates
• Implement automated quality checks
• Use containerization for consistent environments
• Practice continuous integration

3. Change Failure Rate

Definition: The percentage of deployments that result in a failure in production requiring immediate remediation (hotfix, rollback, or patch).

Why It Matters: Low change failure rates indicate high code quality, effective testing, and reliable deployment processes. This metric balances speed with stability.

Measurement Levels:

• Elite: 0-15% failure rate
• High: 0-15% failure rate
• Medium: 16-30% failure rate
• Low: 16-45% failure rate

How to Track:

# Calculate failure rate over last month
TOTAL_DEPLOYS=$(count_deployments_last_month)
FAILED_DEPLOYS=$(count_failed_deployments_last_month)
FAILURE_RATE=$((FAILED_DEPLOYS * 100 / TOTAL_DEPLOYS))

# Track using:
# - Incident management systems (PagerDuty, Opsgenie)
# - Monitoring alerts (Datadog, New Relic, Prometheus)
# - Rollback logs
# - Hotfix deployment records

Improving Change Failure Rate:

• Increase test coverage (unit, integration, e2e)
• Implement comprehensive monitoring and alerting
• Use canary deployments and blue-green deployments
• Practice chaos engineering
• Improve code review processes
• Implement automated rollback mechanisms

4. Time to Restore Service

Definition: How long it takes to restore service when a service incident occurs (e.g., unplanned outage or service impairment).

Why It Matters: Fast recovery times minimize customer impact and business losses. This metric reflects incident response effectiveness and system resilience.

Measurement Levels:

• Elite: Less than one hour
• High: Less than one day
• Medium: One day to one week
• Low: One week to one month

How to Track:

# Track incident resolution time
INCIDENT_START=$(<alert-timestamp>)
INCIDENT_RESOLVED=$(<resolution-timestamp>)
RESTORE_TIME=$((INCIDENT_RESOLVED - INCIDENT_START))

# Use incident management tools:
# - PagerDuty incident timelines
# - Opsgenie resolution tracking
# - Custom incident tracking systems
# - Monitoring system alert-to-resolution metrics

Improving Time to Restore:

• Implement comprehensive observability (logs, metrics, traces)
• Create runbooks and playbooks
• Practice incident response drills
• Use automated rollback capabilities
• Improve monitoring and alerting
• Establish on-call rotation and escalation procedures
• Document known issues and solutions

DORA Performance Levels

Teams are categorized into four performance levels based on their metrics:

Elite Performers

• Deployment Frequency: Multiple per day
• Lead Time: Less than one hour
• Change Failure Rate: 0-15%
• Time to Restore: Less than one hour

Characteristics: Elite teams show significantly better business outcomes, including 50% higher market capitalization growth and 2.5x faster time to market.

High Performers

• Deployment Frequency: Once per day to once per week
• Lead Time: One day to one week
• Change Failure Rate: 0-15%
• Time to Restore: Less than one day

Characteristics: High performers demonstrate strong DevOps practices and consistently deliver value efficiently.

Medium Performers

• Deployment Frequency: Once per month to once per six months
• Lead Time: One month to six months
• Change Failure Rate: 16-30%
• Time to Restore: One day to one week

Characteristics: Medium performers are improving but have significant opportunities for optimization.

Low Performers

• Deployment Frequency: Fewer than once per six months
• Lead Time: More than six months
• Change Failure Rate: 16-45%
• Time to Restore: One week to one month

Characteristics: Low performers face significant challenges in software delivery and need fundamental process improvements.

Implementing DORA Metrics

Step 1: Establish Baseline Metrics

Before improving, you need to know where you are:

#!/bin/bash
# dora_metrics_collector.sh
# Collect basic DORA metrics

# Deployment Frequency (last 30 days)
echo "=== Deployment Frequency ==="
DEPLOY_COUNT=$(git log --since="30 days ago" --oneline | wc -l)
echo "Deployments in last 30 days: $DEPLOY_COUNT"

# Lead Time (average for last 10 commits)
echo "=== Lead Time for Changes ==="
# This requires integration with your CI/CD system
# Example conceptual calculation:
echo "Average lead time: [requires CI/CD integration]"

# Change Failure Rate
echo "=== Change Failure Rate ==="
# This requires incident tracking
echo "Failure rate: [requires incident system integration]"

# Time to Restore
echo "=== Time to Restore Service ==="
# This requires incident management system
echo "Average restore time: [requires incident system]"

Step 2: Choose Measurement Tools

Deployment Tracking:

• Git tags and releases
• CI/CD pipeline logs (Jenkins, GitLab CI, GitHub Actions, CircleCI)
• Deployment automation tools (Spinnaker, ArgoCD, Flux, and other GitOps tools)

For a practical example of automated deployment tracking, see our guide on Using Gitea Actions to deploy Hugo website to AWS S3 which demonstrates measuring deployment frequency in a real-world CI/CD workflow.

Lead Time Tracking:

• CI/CD pipeline timestamps
• Version control system timestamps
• Deployment system logs

Failure Rate Tracking:

• Incident management systems (PagerDuty, Opsgenie, Jira)
• Monitoring systems (Datadog, New Relic, Prometheus)
• Rollback logs

Restore Time Tracking:

• Incident management systems
• Monitoring alert timelines
• On-call systems

Step 3: Create Dashboards

Visualize your metrics for continuous monitoring:

# Example Prometheus queries for DORA metrics
# Deployment Frequency
rate(deployments_total[30d])

# Lead Time (requires custom metrics)
histogram_quantile(0.95,
rate(lead_time_seconds_bucket[1h])
)

# Change Failure Rate
rate(deployment_failures_total[30d]) /
rate(deployments_total[30d]) * 100

# Time to Restore
histogram_quantile(0.95,
rate(incident_resolution_seconds_bucket[30d])
)

Step 4: Set Improvement Goals

Start with achievable targets based on your current level:

• Low → Medium: Focus on automation and CI/CD basics
• Medium → High: Optimize processes and reduce batch sizes
• High → Elite: Fine-tune and eliminate bottlenecks

Best Practices for Improving DORA Metrics

1. Start with Culture

DORA research shows that culture is more important than tools:

• Foster collaboration between Dev and Ops
• Encourage experimentation and learning from failures
• Reduce blame and focus on systemic improvements
• Share knowledge and documentation

2. Implement Automation

• Automate testing (unit, integration, e2e)
• Automate deployments (CI/CD pipelines)
• Automate infrastructure provisioning (IaC with Terraform, Ansible)
• Automate monitoring and alerting

3. Reduce Batch Sizes

Smaller changes are easier to:

• Test thoroughly
• Review effectively
• Deploy safely
• Rollback if needed

4. Improve Testing

• Increase test coverage
• Implement test automation
• Use test-driven development (TDD)
• Practice continuous testing

5. Enhance Monitoring

• Implement comprehensive observability
• Use distributed tracing
• Set up proactive alerting
• Create dashboards for key metrics

6. Practice Continuous Learning

• Conduct post-incident reviews
• Share learnings across teams
• Document runbooks and procedures
• Practice incident response drills

Common Pitfalls and How to Avoid Them

1. Focusing on Metrics Instead of Outcomes

Problem: Optimizing metrics in isolation without considering business value.

Solution: Always connect metrics to business outcomes. Ask “Why are we improving this metric?” and ensure it delivers customer value.

2. Gaming the Metrics

Problem: Teams artificially inflating numbers (e.g., deploying empty commits).

Solution: Focus on meaningful deployments that deliver value. Quality over quantity.

3. Ignoring Context

Problem: Comparing metrics across different contexts (e.g., web apps vs. embedded systems).

Solution: Understand that different systems have different constraints. Compare against similar systems or your own historical performance.

4. Not Measuring All Four Metrics

Problem: Optimizing one metric while ignoring others (e.g., high deployment frequency but high failure rate).

Solution: Balance all four metrics. Elite performance requires excellence in all areas.

5. Lack of Tool Integration

Problem: Manual metric collection leading to incomplete or inaccurate data.

Solution: Integrate measurement into your existing tools and automate data collection.

Advanced Topics

DORA Metrics and Platform Engineering

Platform engineering teams can significantly improve DORA metrics by:

• Providing self-service developer platforms
• Reducing deployment friction
• Standardizing tooling and processes
• Enabling faster experimentation

DORA Metrics in Microservices

Measuring DORA metrics in microservices architectures requires:

• Aggregating metrics across services
• Understanding service dependencies
• Tracking deployment coordination
• Managing distributed failure scenarios

DORA Metrics and Cloud-Native

Cloud-native technologies can accelerate DORA improvements:

• Kubernetes: Automated deployments and rollbacks
• Service Mesh: Better observability and failure handling
• Serverless: Simplified deployment processes
• Containers: Consistent environments

Conclusion

DORA metrics provide a data-driven framework for measuring and improving software delivery performance. By tracking and optimizing these four key metrics, teams can achieve:

• Faster time to market
• Higher code quality
• Better team satisfaction
• Improved business outcomes

Remember that these metrics are a means to an end - better software delivery that creates value for customers. Focus on continuous improvement, cultural change, and balancing all four metrics to achieve elite performance.

Start measuring your DORA metrics today, establish baselines, and begin your journey toward DevOps excellence.

Measuring Success

Track your improvement over time:

1. Baseline: Establish current metrics
2. Quarterly Reviews: Assess progress every quarter
3. Goal Setting: Set realistic improvement targets
4. Celebrate Wins: Recognize improvements and learnings
5. Continuous Improvement: Never stop optimizing

Useful Links

• DORA Research Program
• Accelerate State of DevOps Report
• Google Cloud DevOps Metrics
• DORA Metrics in Practice
• Four Keys Project - Open-source tool for measuring DORA metrics

Related Articles on this Website

• GIT commands cheatsheet
• GitHub Actions Cheatsheet
• Using Gitea Actions deploy Hugo website to AWS S3
• DevOps with GitOps - Argo CD, Flux, Jenkins X, Weave GitOps and others
• Gitflow Explained: Steps, Alternatives, Pros, and Cons