DORA metrics 2026: the 4 indicators that actually measure your delivery.

Why DORA metrics, and why now

Measuring an engineering team by lines of code or story points is like measuring a car's speed by engine noise. DORA metrics — from Google's DevOps Research and Assessment program, popularised by the book Accelerate — propose something different: four indicators that look at what actually matters, the team's ability to ship change fast without breaking everything.

Their strength is their restraint. Four numbers, two axes: velocity (how fast you ship) and stability (how much you break while shipping). The myth that you must choose between the two is false — Elite teams are both faster AND more stable. That trade-off-free reality is exactly what DORA metrics make visible.

The 4 indicators, concretely

Two measure throughput, two measure resilience. Taken together they tell the whole story of your delivery.

• Lead time for changes — the time between a merged commit and its release to production. This is the headline metric: it aggregates the quality of your CI, your tests, your environments and your review process. A lead time counted in hours is the sign of a healthy pipeline.
• Deployment frequency — how often you ship to production. An Elite team deploys on demand, several times a day. Shipping often shrinks batch size, and therefore the risk per deployment. Frequency is not a goal in itself; it is the consequence of a system that knows how to ship small.
• Change failure rate — the percentage of deployments that cause an incident (rollback, hotfix, service degradation). It measures the quality of what you push. A low rate achieved by deploying once a month is unimpressive: always read it against frequency.
• Mean time to restore (MTTR) — the average time to get back to normal after an incident. This is the humility metric: it assumes incidents happen, and measures your ability to absorb them. A short MTTR is often more valuable than a zero-but-artificial change failure rate.

DORA sorts teams into four tiers — Low, Medium, High, Elite. The point is not to earn the Elite badge, but to know where you stand and which way the trend points. A team moving from Low to High in six months tells you far more than a frozen score.

Instrumenting them without building a heavy stack

The classic mistake: wanting a full observability platform before you have your first number. Do the opposite. The data already exists, scattered across three sources you already have at hand.

1. Git and CI/CD for velocity — merge timestamps and the deployment events of your pipeline (GitHub Actions, GitLab CI, ArgoCD) give you lead time and deployment frequency directly. No third-party tool needed to start.
2. The incident tracker for stability — linking each incident to the deployment that caused it lets you compute change failure rate and MTTR. A simple tagging convention on your tickets is enough.
3. A minimal dashboard — one graph per metric, read as a weekly or monthly trend. That's it. Dedicated tools (LinearB, Swarmia, Sleuth) have their place once the culture is in place, not before.

The Abbeal rule: instrument first whatever can be derived from the existing pipeline, add tooling only once the team reads its numbers every week and wants to go further. A dashboard you actually look at beats a platform you've forgotten about.

The traps: vanity metrics and gaming

The day a metric becomes a target, it stops being a good metric — that's Goodhart's law, and DORA metrics are no exception. A few pitfalls to know before you put them on every screen.

• Frequency in isolation is a vanity metric. Deploying 40 times a day says nothing if half the deployments are hotfixes. Frequency is never read without change failure rate next to it.
• Gaming shows up fast. Artificially splitting PRs to inflate frequency, not declaring small incidents to protect the change failure rate: these are human reflexes the moment a number becomes an individual evaluation.
• Never at the individual level. DORA metrics are read by team, by product, as a trend. Using them to rate or compare developers destroys trust and data quality within weeks.
• A snapshot is not a film. A number at a single point in time is worthless. What matters is the direction: is it improving, and what is blocking the next step?

The real point: the link to product performance

DORA metrics are not an engineering beauty contest. Their business value is that they correlate with organisational performance: teams that ship fast and stable shorten their product feedback loop. They test an idea, measure, adjust — several times a week rather than once a quarter.

A short lead time is not a technical luxury: it is the speed at which your product learns from its users. A controlled MTTR is the confidence to try something without betting the house. That is what makes DORA metrics a shared language between engineering and product, where story points only speak to engineers.

Beyond the 4 keys: reliability and SPACE

The four metrics measure delivery throughput and stability — not perceived operational reliability, nor the value actually produced, nor team health. DORA later added a fifth dimension, reliability (the ability to meet your service objectives, in line with SLOs/SLIs), to cover the production-operations blind spot.

And for what the four keys don't see — satisfaction, collaboration, cognitive load — the SPACE framework is the natural complement. DORA metrics remain the best starting point: start with them, broaden afterwards, never the reverse.

How Abbeal uses them on its squads

At Abbeal, DORA metrics are the default dashboard whenever we take ownership of a scope. On staff augmentation as on turnkey delivery, they are the language that aligns team and client on a measured reality rather than a gut feeling.

Our Follow-the-Sun model — synchronised hubs in Paris, Montreal and Tokyo — adds a requirement: a roadmap that moves forward 24/7 only holds if handoffs are clean and delivery is continuous. Lead time and deployment frequency are precisely the numbers that reveal whether the overlap between time zones is working or quietly creating hidden queues.

We've seen it in demanding contexts — banking, high-traffic retail — where every deployment counts and an incident is measured in euros. On a mobility scale-up with Montreal/Paris hubs, work on observability and infrastructure (on the GreenOps side) translated into -30% infra cost and better resilience: the kind of gains DORA metrics make legible and defensible to the business.

Our conviction: DORA metrics are not a dashboard to reassure management, they are an engineer's tool to decide what to improve next. Want to audit the delivery health of a squad or set up this kind of steering on a critical scope? That's exactly the kind of work we do. For the short definition and the Low/Medium/High/Elite tiers, see also our DORA metrics glossary entry: /en/glossaire/dora.