What are DORA metrics?
Length:
5 min
Published:
June 9, 2026
What are DORA metrics?
DORA metrics are four measures of software delivery performance, defined by Google's DevOps Research and Assessment program after years of studying what separates high-performing engineering teams from the rest. They answer two questions every engineering leader cares about: how fast do we ship, and how safely. The four keys are:
- Deployment frequency tells you how often you successfully release to production. More frequent, smaller releases usually mean less risk per release and faster feedback.
- Lead time for changes measures how long it takes from a commit landing in the codebase to that change running in production. Short lead time means the path from idea to customer is clear.
- Change failure rate is the share of deployments that cause a failure needing a fix, such as a rollback, hotfix, or incident. It tells you whether speed is costing you stability.
- Time to restore service (often called MTTR) measures how long it takes to recover when something does break. Fast recovery matters more than never failing.
The first two measure speed (throughput). The last two measure stability. Read together, they show whether your teams move fast and stay reliable, instead of trading one for the other.
In plain words
Think of DORA metrics as the dashboard of a car you are driving toward a release. Two gauges tell you speed: how often you arrive (deployment frequency) and how long each trip takes (lead time). Two gauges tell you safety: how often you crash (change failure rate) and how quickly you get back on the road (time to restore). A good driver watches all four, because going fast only counts if you also arrive in one piece.
Why they matter
DORA metrics turn a vague feeling ("delivery feels slow") into something you can point at, compare over time, and act on. That changes the conversation in three ways.
They give you a shared language. Instead of debating who works hard enough, you and your team look at the same four numbers and ask why lead time doubled last quarter. The discussion moves from blame to bottlenecks.
They connect engineering to business outcomes. Faster lead time means you respond to the market sooner. A lower change failure rate means fewer fire drills and less wasted senior time. Faster recovery means shorter outages and less revenue at risk. These are decisions a CTO or product owner can weigh against cost.
They are research-backed. The DORA program found that teams strong on all four ship more often, recover faster, and report less burnout. So the metrics are not just activity counters. They correlate with outcomes leadership already cares about.
The takeaway: DORA gives you a credible, comparable read on delivery health, the kind you can take into a board meeting without hand-waving.
How to start measuring
You do not need a measurement platform to begin. Start small and make the numbers honest before you make them pretty.
- Pick one team and one service. A single value stream is enough to learn the mechanics. Rolling out across the whole org first usually stalls.
- Pull what your tools already have. Deployment frequency and lead time mostly live in your CI/CD pipeline and version control. Change failure rate and recovery time come from your incident tracker or on-call tool. Most teams can assemble a first read from existing logs.
- Agree on definitions before you trust a number. What counts as a "deployment"? When does lead time start, at commit or at merge? When is an incident "resolved"? Write it down. Inconsistent definitions are the most common reason DORA numbers mislead.
- Look at trends, not absolutes. A single week tells you little. The value is in the direction over a quarter and whether a change you made moved the line.
- Pair the numbers with context. Ask the team what the data does not show. Metrics tell you where friction sits. People tell you why.
Once one team has a reliable baseline, the same approach scales to the next.
Common pitfalls
- Treating DORA as a productivity score. These are delivery-health signals, not a ranking of individuals. The moment people feel measured personally, they optimize for the number instead of the work.
- Gaming the metrics. Anything you reward gets gamed. Teams can inflate deployment frequency with trivial releases or close incidents early to flatter recovery time. If a number improves while the experience clearly does not, look at the definition.
- Chasing vanity numbers. A high deployment frequency means nothing if change failure rate climbs with it. The four keys are a balanced set on purpose. Improving one at the expense of another is not progress.
- Comparing teams that are not comparable. A platform team and a customer-facing product team have different rhythms. Compare each team to its own past, not to each other.
- Measuring without acting. A dashboard nobody uses is overhead. If the numbers do not change a decision, you are collecting data, not improving delivery.
DORA tells you whether delivery is healthy. It does not, on its own, tell you whether developers find the work smooth or painful. For the fuller picture, pair it with a broader framework like DX Core 4.
Related articles:
- DX Core 4: the framework for measuring developer experience - The broader framework that puts DORA's speed and stability signals alongside developer experience and business impact.
- What is Developer Experience and why you should care - What DX means and why the numbers only matter if the day-to-day work feels good too.
- The ROI of Investing in Developer Experience - Why faster, safer delivery is a business decision, not just an engineering one.
Want to stay one step ahead?
Don't miss our best insights. No spam, just practical analyses, invitations to exclusive events, and podcast summaries delivered straight to your inbox.