What Are the DORA Metrics (and How Do You Measure Them)?

Quick answer
DORA metrics are four delivery measures: deployment frequency, lead time for changes, change failure rate, and time to restore service.
Deployment frequency and lead time describe speed; change failure rate and time to restore describe stability.
Measure them from pipeline and incident events, not from surveys or self-reporting.
Track trends over months rather than absolute targets, because the useful signal is whether the system is improving.
Do not use them to rank individuals; they measure a delivery system, and gaming them is easy when they become performance reviews.

What are the four DORA metrics?

Deployment frequency is how often a change reaches production. Lead time for changes is the time from commit to running in production. Change failure rate is the share of deployments that require a hotfix, rollback, or incident response. Time to restore service is how long it takes to recover when a change does cause a failure.

The first two describe throughput, the second two describe instability. Reading them as a pair is the point: a team that deploys ten times a day and breaks something every time is not high-performing, and a team that never deploys has a perfect failure rate only because nothing ships.

How do you measure each one?

Define the boundaries before collecting data, because every metric is sensitive to definition. Deployment frequency counts production deploys, not staging deploys or merges. Lead time starts at the first commit in the change, not at pull-request creation. Change failure rate needs an explicit definition of failure, usually a rollback, hotfix, or incident linked to a deploy.

Instrument the pipeline to emit an event on every production deploy with the commit range and timestamp. Incidents should link back to a deploy when possible. The metrics then become a query rather than a spreadsheet, and the definitions stay stable as the team changes.

| Metric                  | Start                      | End                          | Source of truth          |
|-------------------------|----------------------------|------------------------------|--------------------------|
| Deployment frequency    | Deploy event               | Deploy event                 | CD system                |
| Lead time for changes   | First commit in the change | Deploy to production         | Git + CD events          |
| Change failure rate     | Deploy event               | Incident or rollback linked  | CD + incident tracker    |
| Time to restore         | Incident start             | Service restored             | Incident tracker         |

What are good values?

There is no universal target. DORA’s research groups teams into performance bands, but the bands describe observed practice, not a standard every team should hit. A regulated service with a quarterly release cadence may be behaving correctly for its risk profile; a consumer app deploying monthly is probably leaving recovery risk to accumulate.

Use the metrics comparatively and directionally. If lead time is falling while change failure rate stays flat, the delivery system is improving. If deployment frequency rises and time to restore rises with it, the team is trading stability for speed without noticing.

How do you improve them without gaming them?

Work on the constraint, not the number. Long lead time usually means review queues or manual test gates; high failure rate usually means thin test coverage or large batches; slow restore usually means no rollback path or unclear ownership. Each has a concrete fix that shows up in the metric as a consequence rather than a target.

Never attach these metrics to individual performance. Once deployment frequency is a personal score, people split deploys; once change failure rate is one, people stop recording failures. Keep the measurement at the service or team level and pair it with SLOs, which describe what users actually experience.

Where this bites vibecoders
An AI-assisted team can generate code much faster than it can review or deploy it, so lead time often grows even as commits increase. That shows up as a rising gap between commit volume and deployment frequency. The fix is not more generation; it is smaller changes, automated checks, and a deploy path that does not depend on one person.

Where AI coding assistants get this wrong

Counting merges to main as deployments.
Measuring lead time from pull-request creation, hiding the queue before it.
Treating rollbacks as separate from failures, so change failure rate reads near zero.
Setting absolute targets copied from another company with a different risk profile.
Publishing per-person metrics, which turns them into a target to game.
Ignoring time to restore because it requires incident data the team does not collect.

Checklist

Define each metric’s start and end event in writing.
Emit a deploy event with the commit range and timestamp.
Link incidents and rollbacks to the deploy that caused them.
Report trends monthly, not daily.
Keep metrics at service or team level, never per person.
Pair the four keys with an SLO your users can feel.

FAQ

Are there more than four DORA metrics?

DORA has discussed additional measures such as reliability and rework rate, but the four keys remain the core set. Adding metrics increases the chance of measuring something easy instead of something useful. Start with the four, and add one only when you can name the decision it informs.

Do DORA metrics apply to a solo developer?

They apply to the delivery system, which a solo developer also has. The useful ones are lead time and time to restore; deployment frequency matters less when there is no coordination cost, and change failure rate is noisy at low volume. Track them for yourself, not as a score.

How do you measure time to restore without an incident process?

Start with what you have: the time from an alert firing to the alert clearing, or from a rollback starting to the previous version serving traffic. That is a lower bound, but it is consistent and it improves when rollback improves. Formal incident records can come later.

Why is lead time for changes usually the highest-leverage metric?

Because it exposes waiting, and waiting is where most delivery time goes. A change that takes an hour to write and four days to reach production is not slow because of coding speed. Reducing review queues, manual gates, and batch size usually improves it faster than asking people to work harder.