GUIDE
What Are DORA Metrics? The 4 Key Metrics Explained
Deployment frequency, lead time for changes, change failure rate and mean time to restore — sometimes shortened to "DORA4", and part of a broader category often called software delivery performance metrics. Here's what each one actually measures, in plain English.
What does DORA mean?
DORA stands for DevOps Research and Assessment, a research program (now part of Google Cloud) that spent years studying what separates high-performing software teams from everyone else. Their findings were published in the book Accelerate and in an annual State of DevOps Report — both are where "the DORA metrics" or "the State of DevOps DORA metrics" come from as a term. The research kept landing on the same four numbers as the strongest signal of delivery performance, which is why they stuck as the industry-standard set instead of one of the dozens of other metrics teams have tried over the years.
The 4 DORA metrics
| Metric | What it measures | Why it matters |
|---|---|---|
| Deployment Frequency | How often code reaches production. | A proxy for how small and low-risk each change is. |
| Lead Time for Changes | Time from a commit landing to it running in production. | How fast a fix or feature can actually reach a user. |
| Change Failure Rate | Share of deploys that cause an incident. | Whether speed is coming at the cost of stability. |
| Mean Time to Restore (MTTR) | How long an incident takes to resolve once it starts. | How quickly the team recovers when something breaks. |
Why teams track them
The four metrics come in two pairs, on purpose: deployment frequency and lead time say something about speed, change failure rate and MTTR say something about stability. Tracking only the speed pair rewards shipping fast and breaking things; tracking only the stability pair rewards moving carefully and slowly. Looking at all four together is what makes them useful — they're a check on each other, not four independent vanity numbers.
How teams usually calculate them manually (and where it gets messy)
None of the four require a special tool — you can pull them from CI/CD logs, git history and whatever channel your team uses for incidents, then do the math in a spreadsheet. Where it usually breaks down isn't the arithmetic, it's the definitions staying consistent:
- What counts as "a deploy" — a merge, a CI run, or an actual production release? Different teams (or different people on the same team) quietly answer this differently.
- Which incidents actually trace back to a specific deploy, versus something unrelated that happened to break at the same time.
- Keeping the same definitions consistent team to team, so "our change failure rate" means the same thing in two different squads instead of two different measurement methods wearing the same name.
It's entirely possible to do by hand — it's just easy for the numbers to quietly stop meaning what everyone assumes they mean.
How moasy.tech computes it automatically
moasy.tech recalculates all four DORA metrics straight from what you already sync from GitHub, GitHub Actions, ArgoCD, Vercel, Azure Pipelines, Waroom and incident.io — read-only, no manual rollups. What counts as a production deploy, and which event starts the lead-time clock, is configurable per team, with a company-wide default as fallback — the same "what counts" question that trips up spreadsheets, made explicit instead of assumed. A deploy only counts as a failure when a real incident, classified by your own rules, lands within a configurable window after it. No AI in the pipeline — every number is a direct calculation, not a model's guess.
See the full breakdown on the DORA Metrics feature page, or read the dedicated guide for each metric: Deployment Frequency, Lead Time for Changes, and Change Failure Rate.
Questions about DORA metrics
What does "DORA4" mean? Is it different from DORA metrics?
Same thing. "DORA4" is just shorthand for "the 4 DORA metrics" — deployment frequency, lead time for changes, change failure rate and mean time to restore.
Do I need a tool to track DORA metrics?
No — you can calculate all four manually from CI/CD logs, git history and your incident channel. It's just manual work, and the definitions (what counts as a deploy, which incident traces to which deploy) tend to drift as more teams get involved. Tools like moasy.tech automate the sync and keep the definitions consistent, but the underlying math isn't secret.
Are DORA metrics only for big companies?
No — any team shipping software to production can track them, from a two-person startup to a large engineering org. The metrics scale down fine; what changes with size is how much manual tracking becomes worth automating.