DORA Metrics

The DORA (DevOps Research and Assessment) programme spent years studying what separates high-performing software teams from the rest. It boiled delivery performance down to four metrics.

The four keys

Metric	Type	Question
Deployment frequency	Throughput	How often do we ship to production?
Lead time for changes	Throughput	How long from commit to running in production?
Change failure rate	Stability	What share of deployments cause a failure that needs a fix or rollback?
Time to restore service	Stability	When something breaks, how quickly do we recover?

Later State of DevOps reports add reliability, meaning whether you’re meeting your availability and performance goals. That links straight to SLOs.

The finding that matters

You’d expect speed and stability to trade off: ship faster, break more. The research says the opposite. Elite teams are better at both. Small, frequent changes are easier to test, easier to review and easier to roll back. Speed and safety come from the same practices.

Using them well

• Measure teams and systems, never individuals. Turn DORA metrics into personal targets and Goodhart’s law takes over: people game the number and stop improving the system.
• Measure before and after a change. Splitting a slow pipeline, adding a platform capability, introducing trunk-based development: each should move a specific metric. Check rather than trust feelings.
• Read them together. Deployment frequency rising while change failure rate also rises isn’t progress.

An example

A team whose pull-request checks take most of an hour will batch changes to avoid waiting. Batching raises lead time and makes each deployment riskier. Splitting checks into fast PR checks and heavier merge checks (see Shift Left Testing) should show up as lower lead time first, and over time as a lower change failure rate.

Where they fit

DORA metrics are Observability for the delivery process, and the scorecard for an Internal Developer Platform: if the platform is working, these numbers move.