DORA metrics in practice — what to measure and how to improve delivery
The four DORA metrics in plain terms: deployment frequency, lead time, change failure rate, and MTTR. How to collect them without manual work and what to do with them.
DORA metrics have become the standard way to talk about delivery health, but in practice they're often either not measured at all or measured "for the report" and never used. Let's go through the four metrics on the merits: what each one means, how to collect it without manual work, and what decisions it points to.
What DORA metrics are
DORA (DevOps Research and Assessment) is a research program that identified four indicators statistically tied to team performance:
- Deployment frequency — how often you ship to production.
- Lead time for changes — how long it takes from commit to production.
- Change failure rate — what share of deployments cause a failure.
- Time to restore (MTTR) — how fast you recover production after an incident.
The first two measure speed, the last two measure stability. Mature teams improve both at once — that's what "elite" DORA performance looks like.
Deployment frequency
High deployment frequency isn't a goal in itself — it's a consequence of small batches. When you ship often, each change is small, easier to review, easier to roll back, and easier to diagnose when something goes wrong.
What it points to: if deploys are rare and large, look for bottlenecks in CI/CD, manual steps, and long review cycles. Breaking releases into smaller pieces almost always improves stability too.
Lead time for changes
Lead time shows how long a change lives from being written to reaching production. Long lead time means code gets stuck — in review, waiting for tests, queued for release.
What it points to: break lead time into stages (review, CI, release wait). Usually one or two stages account for most of the delay — that's where to focus.
Change failure rate
Change failure rate is the percentage of deployments that required a rollback, a hotfix, or caused an incident. It's a direct indicator of the quality of what you ship.
What it points to: a rising CFR signals that review and tests are letting problems through. Context-grounded review helps here: checking changes against architecture decisions and past incidents catches exactly the mistakes that cause failures.
Time to restore (MTTR)
MTTR measures how fast you return the system to normal. The point isn't to "never fail" (unachievable) but to recover quickly.
What it points to: high MTTR usually means it's hard to tell what broke. When incidents are linked to specific deploys and PRs, diagnosis takes minutes, not hours.
How to collect DORA without manual work
The main mistake is computing metrics by hand in spreadsheets. It doesn't scale and gets abandoned fast. DORA should be collected automatically from data you already have: deploy events from CI/CD, commits and PRs from Git, incidents from your alerting system.
In ShipGrid, DORA metrics are computed automatically and sit next to review signals — leaders see speed, stability, and the reasons on one screen: which deploys failed and which changes are behind them.
Takeaways
- DORA is a decision-making tool, not a report.
- Improve speed and stability together, not one at a time.
- Link metrics to deploys, PRs, and incidents — that's what turns a number into a concrete action.
Want to see your team's DORA metrics next to review and incidents? Get in touch — we'll show it on your stack.