Guide
What Are DORA Metrics?
The four DORA metrics measure how fast and how safely your team ships software. Here's what each one means, why they matter, and how to start tracking them.
DORA metrics are four measurements that describe how well a software team delivers changes to production. They come from the DevOps Research and Assessment (DORA) program, whose multi-year State of DevOps research found that these four signals correlate with both software delivery performance and broader organizational outcomes.
Two of the metrics describe speed - how quickly you ship - and two describe stability - how safely you ship. The insight that made DORA influential is that speed and stability are not a trade-off. High-performing teams tend to score well on both at once, because the same practices (small batches, automation, fast feedback) improve throughput and reliability together.
The metrics are deliberately outcome-focused. They measure the flow of value into production rather than activity like commits or story points, which makes them hard to game and useful as a shared, team-level health signal.
1. Deployment Frequency - how often you ship
Deployment frequency measures how often your team successfully releases to production. It is a proxy for batch size: teams that deploy many small changes per day have shorter feedback loops and lower risk per release than teams that ship a large batch once a month.
- Elite teams deploy on demand, often multiple times per day.
- Low performers deploy between once per week and once per month.
Count each successful production deploy. Don't confuse this with commit count - merging code that sits behind a feature flag is not a deployment until it reaches users.
2. Lead Time for Changes - how fast code reaches production
Lead time for changes is the elapsed time from a commit being made to that commit running in production. It captures the efficiency of everything in between: code review, CI, testing, approvals, and release. Short lead times mean small, low-risk changes and fast recovery when something is wrong.
Measure the median (not the mean - outliers distort it) from first commit to deploy. If your lead time is measured in days or weeks, look at where time actually accumulates: PRs waiting for review, slow pipelines, or manual release gates. See our lead time for changes guide for a deeper breakdown.
3. Change Failure Rate - how often you break production
Change failure rate is the percentage of deployments that cause a degraded service requiring remediation - a hotfix, rollback, or patch. It balances the two speed metrics: shipping fast is only valuable if most changes work.
- Elite/high/medium teams sit in a roughly 0-15% range.
- A rising failure rate is a signal to invest in testing, review, or smaller batches - not to slow down blindly.
Define "failure" clearly and consistently up front, or the number becomes meaningless. Tie it to real user-facing impact, not every minor blip.
4. Failed Deployment Recovery Time - how fast you bounce back
Failed deployment recovery time (previously "time to restore service" or MTTR) measures how long it takes to recover from a failed deployment or production incident. It reflects the maturity of your observability, rollback tooling, and on-call process.
The goal is to make failure cheap. Teams that can roll back or fix forward in minutes can afford to move fast, because the cost of any single mistake is small. Measure from incident start to full restoration, using your incident timeline or on-call tooling as the source of truth.
5. Read them as a set, at the team level
No single DORA metric tells the whole story - they are designed to be read together. High deployment frequency with a high change failure rate means you are shipping chaos; a great failure rate with a monthly deploy cadence means you are shipping slowly and safely, but slowly.
Never use DORA metrics to rank or evaluate individuals. They are team- and system-level signals. The moment they become a personal performance target, people optimize the number instead of the outcome (Goodhart's Law), and the data stops being useful.
6. Instrument your pipeline to collect the data
You already produce the raw data. The four metrics come from three sources you likely have:
- Version control (Git) - commit timestamps for lead time.
- CI/CD - deployment events for frequency and lead time.
- Incident / on-call tooling - failure and recovery timelines.
Start simple: even a spreadsheet fed by webhook events gives you a baseline. To skip the plumbing, try our DORA metrics calculator or explore automated DORA metrics tracking that wires directly into your repos and pipelines.
7. Establish a baseline, then improve deliberately
Measure your current numbers for a few weeks before changing anything - you cannot improve what you have not baselined. Then pick one constraint and target it.
- Slow lead time? Attack PR review latency and pipeline speed first (see reducing PR review time).
- Low deploy frequency? Shrink batch size and automate the release path.
- High failure rate? Strengthen automated testing and code review quality.
Review trends, not point-in-time values, and revisit weekly. DORA is a compass, not a scoreboard - pair it with qualitative context from your team. See how to measure developer productivity for the wider picture.