DORA Metrics

For a long time there was no good way to see from the outside whether an engineering team was working well. Sales could talk in closed deals and marketing in visits, and engineering had no comparable number. So teams started counting whatever was easiest to count: lines of code written, commits pushed, tickets closed.

Those three share a flaw. They show effort but say nothing about whether the effort reached a user. And once they're measured, they're the only thing that improves. Measure lines and the same feature arrives in more code. Measure tickets and one piece of work gets split into three. Six months later the chart points up and the product a user opens looks the same as before.

An old belief sat on top of that. Shipping fast is risky, the thinking went, and being safe requires being slow. The rules built on that belief are familiar: batch a month of changes into one release, never deploy on a Friday, collect three approvals before anything goes out. Pagedeck worked that way at first. When Grace, the CEO, asked what engineering had done last month, Theo could read out a list of features, but the list couldn't say what reached users or when. Because a month of work went out at once, something broke almost every release night, and just narrowing twenty changes down to the one at fault took three or four hours.

DORA metrics aim at both problems together. DORA — DevOps Research and Assessment — is a multi-year research program on software delivery performance, and pooling responses from thousands of organizations produced a result that contradicted the common belief. Organizations that shipped more often had fewer failures. Teams releasing a month at a time broke more badly than teams releasing several times a day, because a small change has exactly one possible cause when it breaks and is easy to undo.

The way the four were chosen follows from the same work. What survived was the set of measures that actually separated high-performing organizations from low-performing ones; everything else was dropped. What's missing from the list is therefore telling. Team size, language choice, lines of code, and meeting count showed no clear relationship to performance and didn't make it. This is a list of what remained, not a list of what someone wanted to track.

So the four measure outcomes rather than effort. Not how hard something was built, but how quickly the built thing reached users and how much it broke on the way. On the engineering map, this branch belongs to operations — the part concerned with what happens while the system is running. Observability looks at what is going on inside the system. DORA metrics look at the flow by which an organization gets changes out at all.

Four branches sit under this term, one per metric. They pair off and hold each other in check: the first two measure speed, the second two measure stability. Watch one side alone and the other side reliably degrades, which is why the four travel as a set.

The speed pair tracks how changes reach users.

1. Deployment frequency — how many times a team released to production in a given period. A team releasing twice a month and a team releasing five times a day can build the same feature and still deliver it to users at very different moments. A low number usually means a release takes a lot of manual work, and when it does, people naturally batch changes to avoid paying that cost often. Pagedeck's number was 1 back when it shipped monthly; now it's around eight a week. Only what actually reached production counts. A build pushed to a staging server, or code merged behind a switch that's still off, hasn't reached anyone and stays out of the count.
2. Lead time for changes — the time from finishing a piece of code to that change running in production. It's usually read as a median rather than a mean, because one change that sat three weeks over someone's vacation would drag the average around by itself. On teams where this number is long, most of it is waiting. Waiting on review, waiting on tests to run, waiting on a deploy approval. The hands-on-keyboard part is often a few hours somewhere in the middle. The first time Pagedeck measured it, the median was six days and four of them were review queue — six days that hiring another engineer would not have shortened.

The stability pair tracks how much that flow breaks.

1. Change failure rate — the share of releases that caused a failure requiring a rollback or an urgent fix. Twenty releases with one rollback is five percent. The hard part is always the definition of failure. Unless a team decides in advance whether to count only rollbacks, or hotfixes too, or errors no user noticed, each quarter's number gets measured with a different ruler and they all land on the same chart.
2. Time to restore service — how long it takes from the start of an outage until the service works again. Until it works again, not until the cause is understood. The distinction matters because the two moments are frequently far apart. Rolling back the offending release and having users running again in ten minutes, then finding the cause the next day, beats leaving the service down for two hours while someone investigates. Bringing this number down depends on having an incident management procedure settled in advance.

The four stay bundled because each one breaks on its own. Target deployment frequency alone and a team can ship ten empty releases a day that change nothing. Target change failure rate alone and the best possible score comes from shipping nothing at all. Put two speed measures next to two stability measures and each shortcut is blocked by the other side.

Good numbers are better read as a direction than as absolute thresholds. In the research, top-tier organizations release multiple times a day, keep lead time under a day, hold failure rate in the single digits, and restore service within an hour. At the other end, the same four come in at once every few months, several months, tens of percent, and several days. The band boundaries shift a little between editions of the research, so comparing your own team's last quarter with this one is more useful than memorizing a specific figure.

One piece of machinery usually moves all four: continuous integration and continuous delivery (CI/CD), the system that checks a code change automatically and puts it on a server when nothing is wrong. Automated releases raise frequency and cut lead time. Automated tests before release bring failure rate down. A one-step rollback shortens restore time. So a team with four bad numbers almost always turns out to have no such system, or one that still leans heavily on people. Read in the other direction, that means there's no separate project needed to improve the four. Remove the manual steps from the release path one at a time and the numbers follow. Fixing the bottleneck a metric points at, rather than chasing the metric, is how this set is meant to be used.

"Deployment frequency went from twice a week to eight times a week last quarter, and the failure rate held."

A report that says the team shipped more often without breaking more. Saying the two together is the point — frequency alone would be hiding the risk half.

"Median lead time is six days, and four of those are sitting in review."

The slowness isn't in writing code, it's in the review queue. What follows is usually a change to the review rules rather than a request to hire.

"I'll log restore time for this incident at 47 minutes. Root cause analysis continues tomorrow."

Confirming that only the stretch up to service being usable again goes into this metric.

At Pagedeck the four numbers come up once a quarter in the engineering retrospective. Theo puts the table up, and the first thing Grace looks at isn't whether the numbers are high or low but whether they moved in the same direction. Frequency up with failure rate up means a quarter of pushing too hard. Failure rate down with frequency down means a quarter of playing it safe. Neither one is a good sign.

Mia doesn't bring product numbers into this meeting. What she does is help reconstruct what was happening in a month where lead time stretched. Whether the cause was urgent requests chopping work into interrupted pieces or a reviewer being away changes what gets fixed next quarter. The numbers don't supply the cause; they only say where to look.

The decisions that come out of this meeting land on procedures rather than people. A long review queue gets a new rule about assigning reviewers. Slow recovery gets a one-step rollback built first. A retrospective that asks who was slow makes next quarter's numbers look better without changing the underlying flow.

Nobody at Pagedeck sets a target value for any of the four. What gets written down instead is one bottleneck and one change to try against it, and the next quarter's table shows whether that change did anything. Reading the numbers as a result rather than a goal is what keeps them honest, and it is also what keeps the meeting short.

The most common mistake is reading the four as a scorecard for ranking teams. Four clean numbers invite lining teams up side by side. But these values depend heavily on the system a team owns. A team handling payments will show lower frequency at identical skill levels because more has to be verified before release, while a team editing interface copy can ship ten times a day. Start evaluating people with these numbers and teams respond by slicing releases thinner to raise frequency and loosening the failure definition to lower the rate. A year later all four cells look better while the outages users actually experience are unchanged. Restricting the comparison to the same team's last quarter versus this one removes almost all of this, because when you're the benchmark there's no gain in moving your own ruler.

The other common belief is that speed and stability eat each other. Plenty of people have watched haste produce sloppiness, so the assumption feels earned. But that experience comes from pushing large batches quickly. What the research overturned was not the direction of speed but the size of the batch. Ship twenty changes at once and a failure leaves twenty suspects, and rolling back throws away the nineteen that were fine. Ship the same twenty one at a time and you undo only the one that broke, with a single candidate for the cause. Left alone, the belief becomes a loop: the team grows afraid of releasing, fear leads to bigger batches, and bigger batches break harder. That loop is the usual path by which all four numbers get worse.