What DORA metrics actually are
If you have ever sat in a retro where someone says "we need to ship faster" and nobody can point to a number backing that up, DORA is the answer to that gap. The research team ran multi-year surveys across thousands of engineering organizations and found that four specific measurements consistently separated high-performing teams from everyone else, regardless of company size, language, or industry. That is the whole premise: not a framework someone invented in a whiteboard session, but a pattern found in the data.
Quick Answer
DORA metrics are four measures of software delivery performance, developed by Google's DevOps Research and Assessment team: deployment frequency (how often you ship), lead time for changes (how long code takes to go from commit to production), change failure rate (how often a deployment causes a failure), and time to restore service (how fast you recover when it does). A fifth, reliability, was added later to cover operational health beyond individual incidents. They still matter in 2026 because, unlike lines of code or commit counts, they measure what happened to the software rather than how busy someone looked producing it. Below: what each metric means, why AI-generated code made the distinction between "busy" and "shipped" sharper instead of obsolete, and how to track a lightweight version of DORA without buying an enterprise platform.
The four original metrics split cleanly into two categories. Deployment frequency and lead time for changes measure speed: how often you ship, and how long a change takes to get there. Change failure rate and time to restore service measure stability: how often shipping breaks something, and how fast you fix it when it does. The insight that made DORA influential is that speed and stability are not a trade-off. The research consistently found that elite performers were fast and stable at the same time, which broke the old assumption that moving carefully meant moving slowly.
The five metrics, defined plainly
Most developers have heard these terms thrown around in a standup without ever seeing a clean definition. This table gives you the definition, the elite-performer benchmark from DORA's own research bands, and what breaks the number in practice.
| Metric | What it measures | Elite benchmark (roughly) | What breaks it |
|---|---|---|---|
| Deployment frequency | How often you ship to production | On-demand, multiple times a day | Manual release processes, batching changes into big releases |
| Lead time for changes | Time from first commit to running in production | Under one day | Slow review queues, heavy manual QA, deploy freezes |
| Change failure rate | Share of deployments causing a failure in production | 0 to 15 percent | Skipping tests to hit a deadline, insufficient review |
| Time to restore service | How fast you recover from a production failure | Under one hour | No rollback path, unclear on-call ownership, poor observability |
| Reliability | Whether the service meets its own uptime and performance targets | Meets internally defined SLOs | Treating reliability as ops' problem instead of the team's |
Deployment frequency is the metric most people cite first because it is the easiest to brag about, but read alone it is close to meaningless. A team deploying fifty times a day that also has a thirty percent change failure rate is not fast, it is reckless. This is why DORA was always meant to be read as a set, not cherry-picked.
Lead time for changes is the one that most directly reflects your process rather than your product. In practice this number is dominated by wait time, not work time: a change sitting in a review queue, a deploy window that only opens on Tuesdays, a staging environment that is down. Almost always, when a team's lead time is bad, the fix is process, not code.
Change failure rate and time to restore service are the honesty check on the first two. Deploying constantly with a low failure rate and fast recovery means your pipeline actually works. Deploying constantly with a rising failure rate means you found a fast way to ship broken software, which is not the same achievement.
Why DORA survived the AI-generated code era when other metrics did not
This is usually the point where someone asks whether any of these old-school engineering metrics still apply now that a meaningful share of the code is agent-written. It is a fair question, because most of the metrics adjacent to DORA did not survive. Commit counts, lines of code, and story-point velocity have all been quietly discredited over the last two years, and for the same reason: an agent can inflate every one of them in minutes without producing anything real.
DORA metrics dodged that failure mode because they were never measuring activity in the first place. Deployment frequency counts things that reached production, not commits that reached a branch. Change failure rate counts things that broke in the real world, not things that looked risky in review. Claude Code or Cursor can write a two-thousand-line diff in under a minute, but neither can make that diff deploy successfully, and neither can make it avoid causing an incident, except by the code actually being correct. That is the difference between an activity metric and an outcome metric, and it is why the guide to code metrics that matter puts change failure rate at the top of its list for the same reason.
What did shift is the shape of the risk. When agents generate a large share of a diff, change failure rate and time to restore service become more important relative to deployment frequency, not less, because the easiest way to look fast now is to let an agent-generated pull request through review without real scrutiny. You will often see this show up first as review depth quietly dropping while deployment frequency keeps climbing, which is exactly the pattern to watch for. What separates a team using AI well from one racing an AI-shaped illusion of speed is that the failure and recovery numbers stay flat or improve while shipping accelerates.
How to track DORA without an enterprise platform
If you run a fifty-person platform team, you probably already have a DORA dashboard, whether you call it that or not. If you are a solo developer, a small startup, or a freelancer, the framework still applies, it just needs a lighter version, and it pairs naturally with the free git analytics habits from the parent guide. Here is the practical stack, ordered from free to more involved.
- Deployment frequency. Free if you deploy through CI. Count deploy events in your pipeline logs over a rolling thirty days. No tool needed.
- Lead time for changes. Pull the timestamp of the first commit on a merged PR and the timestamp it hit production. Most CI systems expose both.
git logplus your deploy log gets you there in an afternoon. - Change failure rate. Tag hotfixes and reverts with a consistent label (a commit prefix works fine) so the ratio becomes a grep instead of a research project.
- Time to restore service. Track the gap between an incident being flagged and the fix landing. Even a rough manual log beats not tracking it at all.
- Reliability. Set one or two internal targets (uptime, error rate, or response time) that matter for what you ship, and check them monthly. This one does not need a framework, just a number you decide to care about.
The honest catch with all five is that they only tell you what happened to the code after it left your hands. None of them capture the effort or the real hours behind the work, which is a different and equally distorted problem in the AI era. If the question you care about is "how much did shipping this actually cost me," DORA cannot answer it alone. That is the layer covered in engineering productivity metrics and, more specifically, in measuring AI coding productivity, where leverage (output per unit of real effort) picks up where DORA stops.
Where DevClocked fits
If your question is genuinely organizational, deployment frequency across twelve teams, lead time trends by service, change failure rate by pipeline, a purpose-built engineering intelligence platform like Waydev is the better call, and its alternatives for smaller teams are worth a look if the enterprise pricing does not fit. If you just want to log the five numbers above yourself for a side project, a spreadsheet and an afternoon with git log will get you there for free. DevClocked is not a DORA dashboard, and it does not try to be. It answers a narrower, individual question DORA was never built for: what you personally shipped, how much of it came from you versus your AI agents, and what your leverage looked like doing it, backed by a git baseline and real telemetry rather than self-reported hours. Full disclosure: I build DevClocked, so read the comparison with that in mind. Teams optimizing delivery pipelines and individuals proving their own output are different problems wearing similar-looking charts.
Common myths about DORA metrics
"DORA metrics are for managers, not developers." They were built from organizational research, but every one of them is legible at the individual and small-team level, and understanding them helps you argue for process fixes instead of guessing.
"High deployment frequency means high performance." Only if change failure rate and recovery time stay healthy alongside it. Read alone, deployment frequency rewards recklessness as easily as it rewards skill.
"DORA metrics measure productivity." They measure delivery, which is adjacent to productivity but not the same thing. They say nothing about effort, cost, or how much of the work was actually yours, which is a gap the DORA-plus-leverage discussion covers directly.
"You need an enterprise tool to track DORA." Three of the four metrics are a git log and a CI export away. The tooling gets valuable at team scale, not before it.
Related Guides
- Git Analytics in 2026: What Your Repo Data Can (and Cannot) Tell You
- Engineering Productivity Metrics That Actually Work in 2026
- Code Metrics That Matter in 2026 (and the Ones That Lie to You)
- Why GitHub Green Squares Don't Prove You Did the Work
- How to Measure AI Coding Productivity
- Software Engineering Intelligence Platforms in 2026: 6 Tools Compared
