DORA metrics

The DORA research programme found four metrics that describe software delivery performance. They are useful as diagnostics for the delivery system. They are not scorecards for individual engineers.

The four metrics

Walking through the measurement

Measure the four from real events, not from estimates. Use one week as the example.

1. Deployment frequency. Count the production deploys in the week, then divide by the number of days.
2. Lead time. For each change, take the time from its commit to its arrival in production. Look at the typical value, not only the average, because a few long-running changes skew the mean.
3. Change failure rate. Count the deploys that needed a rollback or a hotfix. Divide by the total number of deploys.
4. Time to restore. For each incident, measure from the moment it was detected to the moment service recovered.

Instrument the pipeline and the incident tracker, so that these numbers fall out of the data. Do not track them by hand.

Speed and stability move together

In the research, the teams that deploy often also restore faster and fail less. Small batches are easier to test and to roll back, and strong automation makes each step quick. Gaming one metric does not help. Empty deploys raise frequency and do nothing for the customer.

Common mistakes

• Ranking engineers by DORA numbers. The metrics describe the system, so people will game them.
• Estimating instead of measuring. Guessed numbers are useless for spotting a trend.
• Looking only at the average lead time. A few long changes can hide a problem that most changes have.

Check yourself

1. A team deploys often but burns its error budget. What does that mean? Answer: It is shipping risk, not value. Slow down and stabilise before shipping more.
2. Why do speed and stability tend to improve together? Answer: Small batches and good automation make each deploy fast to ship and quick to roll back.

Key takeaways

• The four DORA metrics are frequency, lead time, change failure rate and time to restore.
• Measure them from real pipeline and incident data, and read them as system health.
• Read frequency next to the error budget, not on its own.
• Never use them to rank individuals.

Further learning

The DORA research site explains the metrics and the survey behind them.

DORA researchDORA is a long running research program that seeks to understand the capabilities that drive software delivery and operations performance. DORA helps teams apply those capabilities, leading to better organizational pe…dora.dev

Next, see how reliability targets set the error budget that these numbers sit beside: SLOs.