Top
Search
People also search for:
Stay Inspired with Instagram
DORA’s five metrics, current benchmarks, and the signals that predict whether a platform is working.
A platform team can spend a year building golden paths. It can still get asked the same question in every leadership review. Is any of this actually working? DORA metrics let a platform team answer that question with data instead of opinion.
DORA is the DevOps Research and Assessment program run by Google Cloud. It has tracked software delivery performance for over a decade. Its research now speaks directly to platform engineering. This guide covers the five metrics, current benchmarks, and what to measure beyond delivery speed alone.
This is written for platform team leads and the engineering leaders who fund them. Both need the same thing: a way to show, with real numbers, whether a platform investment is paying off.
A platform team’s job is to make other teams faster and safer. That makes it hard to point to a single output the way a product team points to shipped features. DORA metrics fill that gap. They measure what a platform is meant to improve: how well applications move from commit to production.
Our platform engineering primer covers what the discipline is and why adoption is accelerating. This guide picks up where that one leaves off, focused specifically on proving the investment is paying off.
DORA’s own research is direct about this. Application teams should see these metrics exposed by the platform. They should not be buried in a dashboard only the platform team checks. A platform that cannot show its own impact on lead time is hard to defend at budget time. The same goes for deployment frequency.
DORA’s model has evolved since it first introduced four keys. As research matured, DORA added a fifth metric: deployment rework rate. The five metrics split into two groups: throughput and instability.
| Category | Metric | What it measures |
| Throughput | Change lead time | Time from a change being committed to running in production |
| Throughput | Deployment frequency | How often an organization deploys to production |
| Throughput | Failed deployment recovery time | How long it takes to recover from a failed deployment |
| Instability | Change fail rate | Share of deployments that require immediate intervention |
| Instability | Deployment rework rate | Share of deployments that are unplanned fixes to a production incident |
Table: DORA’s five software delivery performance metrics. Source: DORA, “DORA’s software delivery performance metrics,” by Nathen Harvey. dora.dev
These metrics work together, not in isolation. DORA’s research has repeatedly found that speed and stability move together for most teams. Top performers do well across all five metrics. Low performers do poorly across all five, rather than trading one for another.
Deployment rework rate is the newest addition, and it catches something the original four metrics missed. A team can deploy often and recover quickly from failures. It can still burn most of its capacity on unplanned fixes to its own incidents. Rework rate makes that pattern visible instead of hiding inside a healthy-looking recovery time.
Context matters when applying them. Track these metrics per application or service, not blended across an entire organization. Comparing a mobile app’s numbers against a mainframe system’s numbers is close to meaningless.
This pattern is not unique to delivery pipelines. Our research on agent reliability found something similar: consistency and predictability lag behind raw capability gains. The same discipline that improves DORA metrics applies there too.
DORA moved away from the old elite, high, medium, low labels in its recent research. It now uses a percentile view of where organizations actually fall. The picture that emerges is less flattering than the old four-tier model suggested.
Source: DORA 2025 benchmark data, analyzed by Research-Driven Engineering Leadership.
Deployment frequency tells a similarly uneven story. Roughly 16 percent of organizations deploy on demand, multiple times a day. Close to 24 percent deploy less than once a month. That gap has not closed much despite years of DevOps investment industry-wide.
Lead time from commit to production varies widely across the industry. Source: DORA 2025 benchmark data, analyzed by Research-Driven Engineering Leadership.
Lead time follows the same pattern. Under 10 percent of teams get a change into production in under an hour. More than 40 percent take longer than a week. That points to pipeline or process bottlenecks rather than any single tool choice.
The takeaway for a platform team is not to chase an elite label overnight. It is to know where your organization actually sits today, then track movement over time.
These numbers also explain why platform engineering adoption is accelerating so fast. Most organizations are not close to elite delivery performance. Generic tooling advice has not closed that gap on its own. A platform built around an organization’s actual bottlenecks is a more direct lever. Another point solution layered on top of an unclear pipeline rarely is.
Our platform engineering cost guide breaks down what closing this gap actually costs, tier by tier. The investment scales with how far your organization sits from these benchmarks today.
DORA’s research centers on one idea, first laid out in its 2025 report. Its January 2026 follow-up sharpens the point further. AI is an amplifier. It strengthens an organization’s existing capabilities and, just as easily, its existing dysfunctions.
Individual developers using AI tools often see a real speed boost. That gain frequently disappears before it reaches the business. Slow testing, security review, or a fragile deployment process absorb it downstream. DORA calls this downstream disorder. It is exactly the failure mode teams exploring AI coding agents need to plan around before rollout, not after.
DORA’s 2026 ROI report adds a specific term for part of this cost: the verification tax. It is the extra effort a team spends checking AI-generated code. That includes reliability, security, and alignment with the system before it ships. Teams that ignore this tax tend to misread a real productivity dip as a tooling failure. It is actually a normal stage of adoption.
A high-quality platform is what prevents that loss. It gives AI-generated code a consistent, tested, secure path to production, turning individual speed into organizational speed. Where platform quality is high, DORA found the effect of AI adoption on performance is strong and positive. Where platform quality is low, that effect is close to negligible.
This is also where developer independence pays off directly. DORA’s 2024 research found that developers who can complete tasks without waiting on another team saw a real gain. Productivity improved 5 percent at both the individual and team level. That is exactly what a well-built golden path is meant to deliver.
The practical implication for a platform roadmap is straightforward. Before adding another AI feature or tool integration, check the deployment pipeline first. Confirm it can actually absorb the extra volume. A faster front door does not help if the rest of the path is still a bottleneck.
One current risk worth naming directly. DORA’s research has flagged a pattern it calls tokenmaxxing. Organizations reward raw AI token consumption through internal leaderboards to push adoption. Treating token spend itself as a performance signal encourages the wrong behavior. Volume is not the same thing as value delivered.
Delivery metrics answer whether software moves through the pipeline well. They do not answer whether developers actually want to use the platform. They also miss whether it solves the right problems.
| Dimension | What to track |
| Delivery performance | The five DORA metrics, tracked per application or service |
| Developer satisfaction | Regular CSAT or Net Promoter Score surveys among platform users |
| Adoption and retention | Rate of new teams onboarding, and whether they keep using it, via the H.E.A.R.T. framework |
| Task success | How efficiently developers complete key workflows on the platform |
Table: A balanced measurement scorecard for platform engineering, per DORA’s own guidance. Source: DORA, “Capabilities: Platform engineering.” dora.dev
DORA’s most recent survey data found one signal correlated most strongly with a positive developer experience. It was not speed. It was clear feedback on the outcome of a task, especially when something failed. A platform that fails silently erodes trust faster than one that is simply slow.
The H.E.A.R.T. framework referenced above breaks adoption into five signals: happiness, engagement, adoption, retention, and task success. A platform can look busy on paper while actually losing teams to workarounds. Tracking retention specifically, not just initial signups, catches that pattern early.
Measuring a platform well is harder than picking a metric and watching a dashboard. DORA’s own guidance flags several recurring mistakes.
| Pitfall | Why It Backfires |
| Turning a metric into a target | Mandating a deploy count invites teams to game the number instead of improving delivery |
| Relying on one metric alone | A single number hides tradeoffs a balanced set of metrics would reveal |
| Comparing across unrelated teams | A mobile app and a mainframe system are not on the same baseline |
| Siloed ownership of metrics | Splitting metrics across teams creates finger-pointing instead of shared accountability |
| Measuring without acting | Dashboards without a follow-up process produce data nobody uses |
Table: Common measurement pitfalls, adapted from DORA’s own guidance.
Two platform-specific traps compound these. The “build it, and they will come” trap happens when a platform ships without real user research. Adoption never materializes. The “ticket-ops” trap happens when a platform team stays in a reactive request queue instead of building genuine self-service. That keeps the team in permanent firefighting mode.
These failure patterns are not unique to platform teams. Our agent architecture guide covers a nearly identical trap in AI agent rollouts. A tool ships without real user research, and adoption never follows.
DORA’s recommended improvement cycle, repeated on a regular cadence.
API DOTS helps engineering teams design platforms with the right metrics built in from day one. Nothing gets bolted on after launch.
Waiting for a perfect measurement system before starting is its own trap. DORA’s recommended approach starts smaller than most teams expect.
DORA’s own Quick Check tool was updated in April 2026 with deployment rework rate and current industry benchmarks. It is a fast way to get a real baseline without building custom tooling first.
Reducing the size of each change is one of the most reliable levers available. Smaller changes are easier to reason about, easier to test, and far easier to recover from when something breaks. That single habit improves throughput and stability at the same time. That is exactly the combination DORA’s research says should move together.
None of this requires a large tooling budget to start. A spreadsheet tracking four or five deployments a week is a better starting point than no data at all. In the first few months, the habit of measuring and reviewing matters more than the dashboard’s sophistication.
Measuring a platform well only matters if the platform itself is built to earn good numbers. API DOTS platform engineering services cover CI/CD pipeline design, infrastructure automation, and the self-service golden paths this guide describes.
We build the DORA metrics and developer feedback loops into the platform from day one. We don’t bolt on anything later as a reporting layer on top of a finished system.
That means a platform team can start showing real delivery impact early, not after a year of guesswork.
Whether you are standing up a first platform team or proving one that already exists, we can help. Our engineers have done both. Reach out to scope what a metrics-first platform would look like for your organization.
DORA metrics are five measurements of software delivery performance developed by Google’s DevOps Research and Assessment program. They cover change lead time, deployment frequency, failed deployment recovery time, change failure rate, and deployment rework rate.
No. DORA’s own guidance recommends pairing delivery metrics with developer satisfaction signals. Adoption, retention data, and task success rates complete the picture.
Only about 16 percent of organizations deploy on demand, multiple times a day. Most teams sit well below that, so steady improvement matters more than hitting an elite label immediately.
No. DORA’s research found AI acts as an amplifier. It strengthens results where the platform is already solid and can worsen instability where it is not.
DORA describes a J-curve pattern. Teams often see an early gain, then a dip as complexity increases. Performance then recovers and stabilizes at a higher level.
API DOTS builds platform engineering programs with delivery metrics, developer feedback loops, and clear ROI reporting.
We leverage AI, cloud, and next-gen technologies strategically.Helping businesses stay competitive in evolving markets.
Consult Technology Experts
Hi! I’m Aminah Rafaqat, a technical writer, content designer, and editor with an academic background in English Language and Literature. Thanks for taking a moment to get to know me. My work focuses on making complex information clear and accessible for B2B audiences. I’ve written extensively across several industries, including AI, SaaS, e-commerce, digital marketing, fintech, and health & fitness , with AI as the area I explore most deeply. With a foundation in linguistic precision and analytical reading, I bring a blend of technical understanding and strong language skills to every project. Over the years, I’ve collaborated with organizations across different regions, including teams here in the UAE, to create documentation that’s structured, accurate, and genuinely useful. I specialize in technical writing, content design, editing, and producing clear communication across digital and print platforms. At the core of my approach is a simple belief: when information is easy to understand, everything else becomes easier. Reach me at amysbrew.com