Engineering Excellence

DORA Metrics

Intermediate

DORA research (the State of DevOps reports) found four metrics that together predict software delivery performance. It also showed that fast teams are usually stable teams. Speed and stability go together. The four metrics are Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Failed Deployment Recovery Time (MTTR). Measure all four together. Improving them means improving how we ship.

DORA (DevOps Research and Assessment) studied thousands of teams. It found four metrics that separate the best teams from the worst. The metrics come in two pairs. Two measure throughput (speed). Two measure stability. The best teams score well on both at the same time. So you do not have to trade speed for safety. The practices in our handbook move these numbers: trunk-based development, CI/CD, testing, small changes, and automation.

The four metrics are: Deployment Frequency (how often you deploy to production), Lead Time for Changes (time from commit to running in production), Change Failure Rate (the share of deploys that cause a failure needing a fix), and Failed Deployment Recovery Time (how fast you recover from a failed change). Watch them as a set. Never improve one on its own.

Measure the four keys together

AlwaysTrack all four metrics as a balanced set: two for throughput (Deployment Frequency, Lead Time) and two for stability (Change Failure Rate, Recovery Time). Do not track only the ones that look good.
DoMeasure Deployment Frequency: how often changes reach production. Smaller, more frequent deploys usually mean lower risk per deploy (see CI/CD & Deployment).
DoMeasure Lead Time for Changes: the time from code committed to running in production. Short lead time means fast feedback and small batches (see Trunk-Based Development).
DoMeasure Change Failure Rate: the share of deployments that cause a failure (rollback, hotfix, or incident). This is the stability metric that balances speed.
DoMeasure Failed Deployment Recovery Time: how quickly you restore service after a bad change. Fast recovery makes shipping safe (see Incident Readiness, Runbooks & On-Call).
DoBuild the metrics automatically from real data (pipeline, deploy, and incident data). Do not collect them by hand. This keeps them trustworthy (see Observability & Logging Hygiene).
ConsiderComparing against DORA's published performance bands to see roughly where we stand and what to aim for next.

Improve them the right way

DoImprove throughput by making batches smaller: small changes, trunk-based development, automated testing and deployment, and feature flags (see Testing Strategy, Feature Flags).
DoImprove stability with strong automated checks, gradual rollout (canary), fast rollback, and good monitoring. Do not slow down or add manual gates.
DoUse the numbers to find bottlenecks. For example, if lead time is long, ask where the work waits. Then run an experiment and measure again (see Continuous Improvement).
DoKeep the metrics at team level and focus on trends. DORA measures the delivery system, not individuals (see Engineering Benchmarking).
AvoidGaming the metrics. Splitting deploys to raise frequency, or hiding incidents to lower Change Failure Rate, defeats the purpose (see Measuring What Matters).
NeverTrade stability for a better throughput number, or the other way round. The best teams are good at both. A fast pipeline that breaks production all the time is not success.

One metric, gamed

// celebrate "deploys per day" only; incidents quietly not counted
// big risky releases still batched; rollback takes hours

This improves deployment frequency alone. It ignores failures and slow recovery, so it hides the real picture. The team can look fast but still be fragile. All four metrics must move together.

Balanced, automated, acted on

// dashboard: Deploy Freq, Lead Time, Change Failure Rate, Recovery Time
// from pipeline + incident data; reviewed in retros; experiments tracked
// trunk-based + tests + canary + fast rollback drive all four

All four metrics are visible and trustworthy. The team reads them together. The practices that improve them are in place. Speed and stability rise together.

Self-review checklist

AskAre we tracking all four metrics, or only the ones that look good?
AskAre they built automatically from real pipeline and incident data?
AskWhen we improve speed, does stability hold? And the other way round?
AskAre we using them to find and fix bottlenecks, or only to report numbers?

Why it matters: The DORA metrics are the best-tested measure of software delivery performance we have. They show that our way of working (trunk-based, automated, small batches) makes us both faster and safer. Track all four together. Improve them through better practice, not gaming. This is a clear, evidence-based path to becoming an elite engineering team.