What is DORA Metrics?
Delivery & EngineeringThe four delivery measures from DORA's research: deployment frequency, lead time for changes, change failure rate, and time to restore service. They describe how fast a team ships and how often that speed breaks things.
Why It Matters
A team that reports rising developer speed and flat sprint throughput is not lying. It is measuring one thing and experiencing another. The DORA metrics exist to close that gap, because they measure the delivery system rather than the person inside it.
Two of the four describe speed. The other two describe the cost of that speed. Reading them as a set is the point: deployment frequency alone can rise while change failure rate rises with it, and the second number is what customers experience.
The Four Metrics
Deployment frequency. How often the team releases to production.
Lead time for changes. The elapsed time from commit to running in production, and where a review queue shows up as a number rather than a complaint.
Change failure rate. The share of releases that cause degraded service and require a fix, a rollback, or a hotfix.
Time to restore service. How long recovery takes once something breaks.
How It Works
Measure them from the systems that already record the events: commits, pull requests, deploys, and incidents. Self-reported velocity numbers trend optimistic; pipeline events do not.
DORA’s own research on AI adoption found the split worth watching. Teams adopting AI assistance reported gains in throughput alongside higher instability, which is the pattern you would expect when generation accelerates and verification does not. That is why a program measured only on deployment frequency will look successful right up until the incident review.
Where It Breaks
The metrics are easy to game and easy to misread. Deployment frequency rewards small, trivial releases; change failure rate punishes teams honest enough to log their incidents. Chasing all four at once produces movement without much improvement.
DORA also stops short of the question most leaders ask next. It says whether delivery is healthy, not whether the team is building the right thing, and it says nothing about the review, test, and documentation work that keeps a fast pipeline from producing fragile software.
How Flytebit Handles It
We measure at the sprint level and pair the DORA set with the pipeline signals that move first: PR queue age, review latency, coverage on changed code, documentation freshness, and agent run cost. When generation speeds up, those numbers show whether the gain reached the sprint or stopped at the individual developer. The industry view is on our Software & Technology page, and the organizational version is Vibe Coding Transformation.