DORA metrics and best practices
Summary: how do you know whether your CI/CD is good? The DORA (DevOps Research and Assessment) research program, acquired by Google in 2018, identified four metrics that statistically predict an organization's performance. This lesson details each one with its thresholds, then presents ten concrete best practices to make progress.
1. Where the DORA metrics come from
What makes DORA credible: these are not expert convictions, but statistical results from tens of thousands of responses over more than a decade. That is what distinguishes DORA from the countless "best practices" without empirical foundation.
2. The four metrics
The balance is deliberate: two speed metrics and two stability metrics. This prevents optimizing one at the expense of the other. Deploying 50 times a day with 60% failures is not a performance, and deploying once a year without incident is not one either.
3. The thresholds by performance level
Here are the tiers from recent DORA reports.
| Metric | Elite | High | Medium | Low |
|---|---|---|---|---|
| Deployment frequency | On demand, several times a day | 1×/day to 1×/week | 1×/week to 1×/month | Less than 1×/month |
| Lead time for changes | Less than 1 hour | 1 day to 1 week | 1 week to 1 month | More than 1 month |
| Change failure rate | 0 to 15% | 16 to 30% | 16 to 30% | 46 to 60% |
| Time to restore service | Less than 1 hour | Less than 1 day | 1 day to 1 week | More than 1 week |
How to position yourself honestly: measure your four metrics over the last three months, without rounding in your favor. Most teams believe they are "high" and discover they are "medium". That is normal and useful — an honest measurement is the starting point of any improvement.
Counter-intuitive DORA finding, to remember absolutely: organizations that are elite on speed are also the ones that are elite on stability. Speed and reliability do not oppose each other — it is even one of the most solid results of the program, and it contradicts classic managerial intuition.
4. Metric 1 — Deployment frequency
5. Metric 2 — Lead time for changes
High-impact practical advice: before investing weeks optimizing your pipeline, measure the breakdown of your lead time. If your developers wait on average 14 hours for a pull request to be reviewed, cutting the pipeline from 12 to 8 minutes will change nothing perceptible.
6. Metric 3 — Change failure rate
Important point often misunderstood: a pipeline that fails before production is not a change failure. That is exactly what it is expected to do. The change failure rate only measures what made it to production and caused a problem.
7. Metric 4 — Time to restore service
The most profitable lever on this metric: the one-command rollback. Many teams spend hours diagnosing before repairing, whereas the right reflex is to restore first (rollback), understand afterwards (cold post-mortem). This can take a restore time from 4 hours down to 5 minutes.
8. The ten CI/CD best practices
9. The test pyramid in detail
This is the principle that determines whether your pipeline will be fast or unbearable.
The anti-pattern to avoid at all costs: the inverted pyramid (sometimes called the ice cream cone) — many end-to-end tests, few unit tests. Systematic result: a 45-minute, unstable pipeline that the team ends up ignoring. It is one of the most frequent causes of abandoning a CI/CD initiative.
10. Secrets management — the most critical point
The OIDC approach deserves to be known: it is the reference today. Your GitHub Actions pipeline stores no AWS key. It presents an identity token signed by GitHub, and AWS grants it a temporary fifteen-minute role. No long-lived secret exists, so no secret can leak.
11. How to measure your metrics in practice
Advice to get started: do not look for the perfect tool. Start with a spreadsheet this week. An approximate measurement that you actually look at is infinitely better than a perfect dashboard nobody consults.
Usage warning: the DORA metrics are designed for a team to improve itself, not to compare teams with each other or to evaluate individuals. Used as a managerial control tool, they will be gamed — Goodhart's law fully applies.
Remember in 30 seconds
- DORA = research program since 2014, the book "Accelerate" (2018), acquired by Google.
- Two speed metrics: deployment frequency, lead time for changes.
- Two stability metrics: change failure rate, time to restore service.
- Elite level: several deployments per day, lead time under 1 hour, less than 15% failure, restore in under 1 hour.
- Counter-intuitive result: speed and stability progress together, they do not oppose each other.
- Lead time is often dominated by waiting for code review, not by the pipeline duration.
- Test pyramid: many unit tests, few end-to-end tests. The inverted pyramid kills pipelines.
- Secrets: aim for OIDC federated identity, with no long-lived secret at all.
- The metrics are for improving, never for evaluating people.