DORA's five delivery metrics are a sound base for judging AI assistants, because they cover both speed and stability. Watch change lead time and deployment frequency for throughput, and change fail rate and rework for instability. If speed rises while stability falls, the tool is not helping yet.
The five metrics
DORA groups them into throughput and instability.
Throughput:
- Change lead time. How long a change takes to go from commit to production.
- Deployment frequency. How many deployments occur in a period, or the time between them.
- Failed deployment recovery time. How long it takes to recover from a deployment that needs immediate intervention.
Instability:
- Change fail rate. The share of deployments that need immediate intervention, such as a rollback or hotfix.
- Deployment rework rate. The share of deployments that are unplanned and result from a production incident.
What to expect after adding assistants
Assistants mostly act on the front of the pipeline, where code is written. Change lead time is the first number that can move, but it can move because pull requests are bigger or reviewed more lightly. Watch the instability side at the same time.
DORA's 2025 report page describes AI as an amplifier that magnifies an organization's existing strengths and weaknesses. That suggests a useful reading: if your tests and review are strong, more code flows safely, and if they are weak, failures also rise.
A reading guide
- Lead time down, change fail rate flat: good sign, keep going.
- Lead time down, change fail rate up: you are shipping faster and breaking more. Look at review depth and test quality.
- Deployment frequency up, rework up: more releases are triggering incidents.
- Everything flat: the tool may not be where your bottleneck is. Look at review queues or release process.
Misuse DORA warns against
The guidance lists these mistakes: setting the metrics as goals, which invites gaming; relying on one metric; using industry or regulation as a shield; comparing very different systems; siloing ownership; competing instead of improving; and building elaborate measurement before improving anything. It suggests starting with conversations or the DORA Quick Check if instrumenting is costly.
Practical advice
Measure per service, not per person. Keep a quarterly baseline from before the rollout. Annotate your charts with the dates tools were introduced. Do not tie compensation or rankings to any of these numbers.
Setting it up in a week
Pull the last quarter of data from your deployment pipeline and incident tracker. Define what counts as a failed deployment in one sentence and write it down, because different teams often mean different things. Chart the five numbers per service, mark the date assistants arrived, and review them in a monthly retrospective instead of a dashboard nobody opens. If you cannot instrument everything, start with change lead time and change fail rate, which together show speed against stability.
Interpreting small samples
A team that deploys a few times a month will see noisy numbers. One incident can swing the change fail rate. Look at trends over quarters, not weeks, and pair the figures with notes from the team about what changed.
Quick check
Which DORA metrics show instability?
Change fail rate and deployment rework rate.
Should teams be ranked by DORA metrics?
No. DORA lists competing as a misuse, because the metrics are meant to guide improvement over time.
Sources
Last reviewed: 19 October 2026.
