DORA metrics without spreadsheets: deriving the four from systems you already run
Updated
The four DORA metrics can be derived from version control, CI and incident tooling without anyone filling in a form. The hard part is not collection but the definitional choices: two teams measuring lead time differently produce numbers that cannot be compared with each other.
This guide covers where each metric comes from, the specific decision each one hides, and why a survey-collected DORA number and a system-derived one should never be put in the same chart.
Where each metric actually comes from
All four are derivable from events your systems already emit. Deployment frequency and time to restore come from deployment and incident records; lead time comes from version control joined to deployment; change failure rate needs deployments joined to the incidents or rollbacks attributable to them, which is the only one of the four that genuinely requires a link between two systems.
The DORA research program itself has historically measured these by survey, which is appropriate for a cross-industry benchmark and a poor fit for steering one team. A survey answer is a memory; a derived answer is a record. Both are legitimate, and they are not the same measurement — which is why mixing them in one trend line is misleading even when the numbers look similar.
| Metric | Derived from | The decision it hides |
|---|---|---|
| Deployment frequency | Deployment or release events per environment. | What counts as a deployment — production only, or every environment? Does a config change count? |
| Lead time for changes | Commit timestamp joined to the deployment that shipped it. | Does the clock start at first commit, at PR open, or at merge? Each answer moves the number by a lot. |
| Change failure rate | Deployments joined to incidents or rollbacks attributed to them. | What counts as a failure, and how you attribute one to a specific deployment. |
| Time to restore service | Incident open and resolve timestamps. | When an incident is considered started — first alert, first human acknowledgement, or customer impact? |
The definitional choices that decide whether the number means anything
Lead time is the clearest example. Starting the clock at first commit includes the time a change sat in a branch, which is often most of it; starting at merge measures only the deployment pipeline. Both are defensible and they can differ by an order of magnitude, so a lead-time figure without its definition attached is not a measurement, it is a number.
Change failure rate hides an attribution problem rather than a timing one. It requires deciding that a given incident was caused by a given deployment, and that decision is frequently made by a human after the fact. If your tooling infers it automatically, understand the inference rule before you trust the trend — an automatic rule that attributes every incident to the most recent deployment will produce a stable and meaningless number.
- Write down the definition next to the number. A DORA figure without its definition cannot be compared to anything, including your own past.
- Change the definition rarely, and mark the trend where it changed rather than restating history.
- Prefer a definition your systems can produce without a human judgement in the loop, then live with it.
What the four metrics do not measure
The four are throughput and stability signals for a delivery pipeline. They say nothing about whether the software is worth deploying, whether the team can sustain the pace, or whether the code will be maintainable next year. The DORA program has always paired them with cultural and wellbeing measures for exactly that reason, and a dashboard that shows only the four inherits a bias toward speed.
They also do not survive being made a target. Deployment frequency in particular is trivially inflatable — split the same work across more deployments and the number improves while nothing about the system does. Watch the four together, alongside a counter-metric, and treat a single improving metric with the suspicion it deserves.
Getting to a derived number honestly
The practical order is: pick the definitions and record them, derive from systems rather than asking people, and leave a metric UNMEASURED where the data does not support it rather than filling the gap with an estimate. A dashboard with two real metrics and two blanks is more useful than one with four numbers where two came from a guess, because only the first tells you what to go and instrument.
That last point is the one most often traded away. An empty cell looks like a failure of the tool and is actually a correct answer, and the moment it is filled with a plausible default the reader can no longer tell which numbers to trust.
- Derive from records, not recollection.
- Record the definition alongside the number, permanently.
- Leave unmeasurable metrics visibly empty; a plausible default destroys the reader's ability to tell.
Frequently asked questions
Do we need a dedicated tool to measure DORA metrics?
No. All four are derivable from version control, CI/CD and incident tooling that most teams already run. A tool is worth it when joining those systems consistently across many repositories becomes the work, or when you need the definitions applied identically over time — not because the metrics are otherwise inaccessible.
Should we compare our DORA numbers to the published benchmarks?
Carefully. The published elite/high/medium/low bands come from survey responses across a wide industry sample, and your derived numbers use your definitions rather than the survey's. They are useful for orientation and misleading as a target. Comparing your own trend against your own past, with the definition held constant, tells you far more.
Which metric should we instrument first?
Deployment frequency, because it needs one system rather than a join, and it forces the first definitional decision — what counts as a deployment — which the other three then reuse. Change failure rate is usually last: it needs deployments linked to incidents, and that link is the hardest to make reliable.
Is a low deployment frequency always bad?
No. Frequency is a proxy for batch size and pipeline confidence, and both matter, but the appropriate cadence for a regulated release train and for a consumer web app are legitimately different. What the metric reliably tells you is whether your cadence is changing, and whether stability moves when it does.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.