DORA Metrics, Read Correctly

The four DORA measures are the most cited framework in this field and among the most frequently misapplied.

The four

Deployment frequency. How often changes reach production.

Lead time for changes. From commit to running in production.

Change failure rate. Proportion of deployments causing a degradation requiring remediation.

Time to restore service. How long recovery takes when something breaks.

The first two describe throughput. The second two describe stability. The central finding is that these do not trade off against each other: teams that deploy more often are also more stable, because small frequent changes are easier to verify and to reverse.

What they are for

Describing a delivery system, at team or organisation level.

Spotting trends, which is where the value is.

Locating a bottleneck. Long lead time with high deployment frequency means the delay is before the pipeline, not in it.

They are not a scorecard, and applying them to individuals is a misuse the framework's own authors have stated explicitly.

How each is gamed

Worth knowing, because a measure with a target attached will be.

Deployment frequency: deploy trivial changes, split one change into five, count non-production environments.

Lead time: open the pull request late, or measure from approval rather than from first commit.

Change failure rate: reclassify incidents, define degradation narrowly, fix forward without recording a failure.

Time to restore: close the incident before it is resolved, or start the clock late.

All four are gamed the same way — by changing the definition rather than the system, which is why definitions should be written down and left alone.

Definitions worth agreeing

Lead time from first commit, not from pull request opened. The earlier point captures the waiting that the later one hides.

Deployment to production only.

Change failure includes anything requiring an unplanned fix, including a rollback and a hotfix.

Time to restore starts at detection, and record detection time separately — a long delay between breakage and detection is its own finding.

Write these down and do not change them, or your trend is measuring your definitions.

Reading them together

High frequency, short lead time, high failure rate: speed without adequate verification.

Low frequency, long lead time, low failure rate: heavy process. Often mistaken for quality, and the failure rate is low partly because so little ships.

Long lead time, high frequency: work waits somewhere before the pipeline — review, approval, environment availability.

Long time to restore: an observability and rollback problem rather than a delivery one.

Any single measure alone is misleading, which is the point of having four.

Where they connect to this site

Lead time is the measure everything else in these notes affects. Build duration, test duration, queue time, flakiness and merge latency all sum into it.

Which makes lead time the useful headline and the toolchain measures the diagnostic breakdown. Reporting only lead time tells you it is bad; reporting the components tells you where.

The benchmark question

Comparing your numbers to published industry benchmarks is mostly unhelpful. Context differs enormously — regulated environments, deployment risk, product type.

Compare against your own trend, which is the comparison that survives scrutiny and the only one you can act on.

Writing the definitions down

The step that makes a trend meaningful, and the one that gets skipped.

Lead time starts at first commit, not at pull request opened.

Deployment counts production only.

Change failure includes any unplanned remediation, including a rollback.

Time to restore starts at detection, with detection delay recorded separately.

Publish the definitions alongside the numbers.

Change them rarely, and annotate the chart when you do, because an unmarked definition change looks exactly like an improvement.

Where the components come from

Lead time is the headline and the toolchain measures are its breakdown.

Coding time — not measurable and not the target.

Waiting for review — frequently the largest component and not a toolchain problem.

Pipeline duration — everything in these notes.

Waiting for deploy — process and risk tolerance.

Report the split alongside the headline, because lead time alone says the number is bad and the split says where.

It also protects the programme from being asked to fix a review latency problem with a faster build.