DevOps Dictionary

DORA Metrics are four software delivery measures used to understand how quickly and safely a team ships changes to production. DORA stands for DevOps Research and Assessment, the research program that popularized these metrics through studies of software delivery performance.

Engineering and DevOps teams use DORA Metrics to track delivery speed, release quality, and recovery ability. They are especially useful for teams running CI/CD pipelines, microservices, cloud infrastructure, and production systems with frequent changes.

The four DORA Metrics

• Deployment frequency: How often a team deploys code to production or releases changes to users. For example, a platform team might deploy 20 times per week, while a regulated backend service might deploy twice per month.
• Lead time for changes: How long it takes a code change to move from commit, merge, or pull request approval into production. Teams should define the start point consistently.
• Change failure rate: The percentage of production changes that cause an incident, rollback, hotfix, failed deployment, or service degradation.
• Mean time to restore service: How long it takes to recover from a production failure after it is detected. Many teams track this as MTTR, or mean time to recovery.

What DORA Metrics measure

DORA Metrics measure the flow of software changes through your delivery process and the operational impact of those changes. They help answer practical questions such as:

• How often do we ship production changes?
• How long does a typical change wait before reaching users?
• How often do deployments break something?
• How quickly can we restore service when production fails?

Strong delivery performance usually means a team can deploy frequently, keep lead times short, keep failure rates low, and recover quickly when failures happen.

How teams collect DORA Metrics

Teams usually collect DORA data from existing engineering systems rather than manual reports. Common sources include:

• Version control: GitHub, GitLab, Bitbucket, or Azure Repos for commits, pull requests, merges, and timestamps.
• CI/CD systems: Jenkins, GitHub Actions, GitLab CI, CircleCI, Buildkite, Argo CD, or Spinnaker for build and deployment events.
• Incident tools: PagerDuty, Opsgenie, FireHydrant, incident.io, Jira Service Management, or ServiceNow for outages and recovery times.
• Monitoring and observability tools: Prometheus, Grafana, Datadog, New Relic, or OpenTelemetry-based platforms for service health and incident detection.
• Change management systems: Jira, Linear, ServiceNow, or internal release systems for approvals and change records.

The hardest part is usually defining each metric clearly. For example, one team may measure lead time from first commit, while another measures it from pull request merge. Both can work, but teams need consistent definitions if they want reliable trends.

Common use cases

• Improving CI/CD pipelines: DORA Metrics can reveal slow test suites, manual approval bottlenecks, flaky builds, or long deployment queues.
• Tracking platform engineering impact: Platform teams can use these metrics to see whether internal developer platforms, templates, or deployment automation reduce delivery friction.
• Reducing production risk: A rising change failure rate can point to weak testing, poor rollout controls, missing feature flags, or risky batch releases.
• Improving incident response: Long recovery times can expose gaps in alerting, runbooks, ownership, rollback processes, or observability.
• Planning engineering investments: Leadership can use trends to justify work on build performance, automated testing, deployment safety, or service reliability.

Simple example

A team owns a payments API and tracks DORA Metrics for one month:

• Deployments: 40 production deployments
• Median lead time for changes: 90 minutes from merge to production
• Failed changes: 2 deployments required rollback or hotfix
• Change failure rate: 5%
• Median time to restore service: 25 minutes

This data tells the team that deployment speed is healthy, but the two failed changes deserve review. They might inspect test coverage, rollout strategy, feature flag usage, and alert quality for those incidents.

Benefits

• Clear delivery signals: The metrics focus on outcomes rather than activity counts such as story points or number of commits.
• Shared language: Developers, SREs, platform teams, and engineering leaders can discuss delivery performance using the same terms.
• Process improvement: Trends can help teams find bottlenecks in code review, testing, deployment, and incident response.
• Balanced view: The metrics include both speed and stability, which helps avoid optimizing for deployment volume alone.

Limitations and tradeoffs

• Definitions matter: Inconsistent definitions can make the metrics misleading, especially across teams or services.
• They do not measure everything: DORA Metrics do not directly measure customer value, product quality, security posture, maintainability, or developer experience.
• They can be gamed: If used as individual performance targets, teams may change behavior to improve numbers rather than improve delivery.
• Context matters: A mobile app, internal platform service, embedded system, and high-volume SaaS API may have very different delivery constraints.
• Data can be messy: Monorepos, shared deployment pipelines, manual hotfixes, and partial rollouts can make attribution difficult.

DORA Metrics vs. engineering productivity metrics

DORA Metrics focus on software delivery and operational performance. They do not replace broader engineering productivity frameworks such as SPACE, which considers satisfaction, performance, activity, communication, and efficiency.

Use DORA Metrics when you want to understand how changes move into production and how production systems recover. Use broader productivity measures when you also need to understand developer experience, collaboration, code health, and team workload.

Good practices for using DORA Metrics

• Track trends over time instead of using one snapshot.
• Measure at the team or service level, not the individual developer level.
• Write down the exact definition of each metric.
• Pair the numbers with incident reviews, deployment reviews, and developer feedback.
• Segment data by service, repository, or deployment pipeline when one aggregate number hides useful detail.
• Use the metrics to guide improvement work, not to rank teams without context.

Used well, DORA Metrics give technical leaders and delivery teams a practical way to see whether their release process is fast, stable, and recoverable.