The Four Key Metrics (DORA)

You can’t improve what you can’t measure — and worse, if you measure the wrong thing, you’ll optimise yourself straight into a ditch. Measure only speed and you’ll ship fast and break everything. Measure only stability and you’ll freeze, shipping nothing to avoid risk. The question that defines good DevOps measurement is: what four numbers, taken together, capture speed and stability so you can’t game one by sacrificing the other?

The answer comes from DORA — the DevOps Research and Assessment program, a multi-year study of tens of thousands of professionals (later published in the book Accelerate). DORA found that the performance of a software team can be captured astonishingly well by just four metrics. They split cleanly into two pairs.

The two pairs

   SPEED (throughput)              STABILITY (reliability)
   ──────────────────             ───────────────────────
   1. Deployment Frequency        3. Change Failure Rate
   2. Lead Time for Changes       4. Time to Restore Service

The design here is the whole point. Two metrics measure how fast you go; two measure whether you stay up. You cannot look good on all four by cheating, because the pairs pull against each other: deploy recklessly to boost frequency and your change failure rate spikes; freeze deploys to protect stability and your frequency craters. Only a team that has genuinely made deploys safe can score well on both pairs at once. The four metrics together are a lie detector.

1. Deployment frequency

How often do you successfully release to production?

This is the speed metric you can see from orbit. Elite teams deploy on demand — many times a day. Low performers deploy between once a month and once every few months. Recall from feedback loops why high frequency is a marker of health, not recklessness: deploying often is only possible if each deploy is small and automated, and small automated deploys are the safe kind. Frequency is a proxy for “we’ve made shipping cheap.”

2. Lead time for changes

How long from code committed to code running in production?

The clock we defined last page. Elite teams measure this in less than an hour; low performers in weeks to months. Where deployment frequency asks “how often does the pipe fire?”, lead time asks “how long is the pipe?” A short lead time means a tight feedback loop — you learn from real users almost immediately. It’s short because the manual, waiting steps between commit and production have been automated away.

3. Change failure rate

What percentage of deployments cause a failure in production (a rollback, hotfix, or outage)?

The first stability metric. Elite teams sit around 0–15%; low performers can be several times higher. This is the honesty check on speed: it catches the team that “deploys constantly” by shipping broken code constantly. The insight from the data — and it surprises people — is that the fast teams also have the low failure rates. Speed didn’t cost them quality. We’ll see why on the next page.

A rate, not a count

Change failure rate is a percentage, not a number of incidents. A team deploying 50 times a day with a 5% failure rate has more raw incidents than a team deploying once a month — but a far healthier system, because each failure is tiny, instantly diagnosed, and quickly reverted. Always compare the rate, never the count.

4. Time to restore service

When something does break, how long until service is healthy again?

The second stability metric, and the most psychologically important one, because it reframes failure. Elite teams restore in under an hour; low performers can take days. The deep idea: you can’t prevent every failure, so optimise for fast recovery instead of trying for zero failures. A team that recovers in five minutes can tolerate far more risk than a team that takes two days — which means fast recovery is what unlocks moving fast. This idea, “design for recovery, not just prevention,” runs right through observability and SRE.

Speed and stability, paired on purpose

                  SPEED                          STABILITY
   ┌────────────────────────────┐   ┌────────────────────────────┐
   │ Deployment Frequency        │   │ Change Failure Rate         │
   │   how often you ship        │   │   how often a ship breaks   │
   │ Lead Time for Changes       │   │ Time to Restore Service     │
   │   how long commit→prod      │   │   how fast you recover      │
   └────────────────────────────┘   └────────────────────────────┘
        "are we moving?"                  "are we staying up?"

A healthy team improves a metric from both boxes at once. Improve only the left and you’re a hazard; improve only the right and you’re a museum. The genius of the four-metric set is that it makes the tradeoff visible — and then the DORA data shows the tradeoff is largely an illusion.

Elite vs low performers

A rough sketch of the spread DORA has reported (exact figures shift year to year; learn the shape, not the digits):

Metric	Elite	Low
Deployment frequency	On demand, many/day	Once per 1–6 months
Lead time for changes	Less than an hour	1–6 months
Change failure rate	0–15%	Much higher
Time to restore	Less than an hour	About a week

The headline finding

Elite teams are better on all four at once. They deploy far more often, with shorter lead times, and fail less, and recover faster. The data does not show a frontier where you trade speed for stability — it shows the best teams winning on both. That single finding is the empirical backbone of this entire book.

Using the metrics without abusing them

These are diagnostic metrics for a team’s system, not a stick to beat individuals with. Turn any of them into a personal target and people will game it: chase deployment frequency and they’ll split one change into ten meaningless deploys; punish change failure rate and they’ll stop reporting incidents — destroying the very honesty the metric needs. (This is Goodhart’s Law: “when a measure becomes a target, it ceases to be a good measure.”) The right use is a feedback loop on your process, which is exactly the measurement and blameless culture we turn to next.

The thread: DORA’s four numbers are how you see whether removing manual steps is working. Automate the deploy path and frequency rises while lead time falls; standardise it and the failure rate drops; invest in recovery and time-to-restore shrinks. The metrics make the safety dividend of killing manual, error-prone steps visible — so you can prove production got safer, not just hope it did.

By the numbers — why you compare the rate, not the count

Turn the “rate vs count” point into arithmetic (figures illustrative):

incidents/month = deploys/month × change-failure-rate
   Team A:  ~50/day × ~20 days × 5%   ≈  50 incidents/month
   Team B:  1/month            × 30%  ≈  0.3 incidents/month

Team A suffers well over a hundred times more incidents — yet runs the far healthier system, because each one is a tiny, instantly-diagnosed change reverted in minutes, while Team B’s rare failure is a 200-change pile-up that takes days to untangle. Count the incidents and you’d “prove” Team A is reckless; measure the rate (and pair it with time-to-restore) and the truth flips. That is why DORA reports a rate: it’s the one number that doesn’t punish a team for deploying often.

Check your understanding

1. List the four DORA metrics and sort each into the speed pair or the stability pair.
2. Why is it essential to measure both pairs? What goes wrong if you optimise only speed, or only stability?
3. Why is change failure rate measured as a rate rather than a count of incidents? Use a high- and a low-frequency team to illustrate.
4. Explain “design for recovery, not just prevention.” How does a short time-to-restore let a team safely take on more risk?
5. Give one concrete way each of two different DORA metrics could be gamed if used as a personal target, and name the law that warns about this.

Show answers

1. Speed pair: deployment frequency, lead time for changes. Stability pair: change failure rate, time to restore service. Two measure how fast you go, two measure whether you stay up.
2. Because the pairs are a lie detector: you can’t look good on all four by cheating. Optimise only speed and you deploy recklessly — change failure rate spikes (you ship fast and break everything). Optimise only stability and you freeze — frequency craters and you ship nothing. Only a team that made deploys genuinely safe scores on both.
3. A count punishes high-frequency teams unfairly. A team deploying 50×/day at a 5% failure rate has more raw incidents than a once-a-month team but a healthier system, because each failure is tiny, instantly diagnosed, and quickly reverted. Always compare the rate, never the count.
4. You can’t prevent every failure, so optimise for fast recovery instead of chasing zero failures. A team that restores in five minutes can tolerate far more risk than one that takes two days — cheap recovery collapses the cost of being wrong, which is exactly what unlocks moving fast.
5. E.g. deployment frequency → split one change into ten meaningless deploys; change failure rate → stop reporting incidents (destroying the honesty the metric needs). The warning is Goodhart’s Law: “when a measure becomes a target, it ceases to be a good measure.” DORA metrics diagnose a team’s system, not individuals.