DORA Metrics: Measure Engineering Performance Across Your Architecture
Most engineering teams can tell you what they shipped. Very few can tell you how fast they shipped it, how often it broke, or how long it took to recover when it did. The deployment count is there. The quality signal is not.
This blind spot exists because delivery performance and architecture documentation have always lived in separate worlds. Your CI/CD tool knows about pipelines. Your architecture tool knows about systems. Neither knows enough to answer the question that actually matters: is your team getting better at delivering software?
DORA metrics bridge that gap — and Archyl now computes them automatically from your release data.
The Four Metrics That Matter
In 2018, the DORA team (DevOps Research and Assessment, now part of Google Cloud) published research showing that four specific metrics predict software delivery performance better than anything else. They've since become the industry standard for measuring engineering effectiveness:
Deployment Frequency — How often your team deploys to production. Elite teams deploy on demand, multiple times per day. Low performers deploy between once per month and once every six months.
Lead Time for Changes — How long it takes from code commit to production deployment. Elite teams measure this in hours. Low performers measure it in months.
Change Failure Rate — What percentage of deployments cause a failure in production (requiring a hotfix, rollback, or patch). Elite teams stay below 5%. Low performers exceed 46%.
Mean Time to Restore (MTTR) — When a production failure occurs, how long does it take to recover? Elite teams restore service in under an hour. Low performers take between one week and one month.
What makes DORA powerful isn't any single metric — it's the four together. A team that deploys ten times a day but breaks production half the time isn't performing well. A team with zero failures but one deploy per quarter is playing it too safe. The four metrics create a balanced scorecard that rewards both speed and stability.
DORA in Archyl: Built on Your Release Data
Here's the thing about DORA metrics: the raw data already exists if you're tracking releases. Every release has a timestamp, a status, and an environment. That's enough to compute all four metrics automatically.
If you've been using Archyl's Release Management — whether through GitHub Actions, webhooks, or the REST API — you already have the data. We just needed to do the math.
Deployment Frequency is computed from the count of successful production deployments over a given time window. If you shipped 45 releases to production in the last 30 days, your deployment frequency is 1.5 per day.
Lead Time for Changes is the time between a release being created (or the commit timestamp, when available) and its successful deployment to production. Archyl computes the median across all releases in the period.
Change Failure Rate looks at releases with a status of Failed or Rolled Back as a percentage of total deployments. If you deployed 40 times and 3 of those were rolled back, your CFR is 7.5%.
Mean Time to Restore measures the time between a failed deployment and the next successful one to the same environment. This captures how quickly your team recovers from incidents.
All four metrics are computed automatically. No configuration, no manual input. If your releases are flowing into Archyl, DORA metrics are already there.
The DORA Scorecard
Each metric is classified into one of four performance levels, based on the benchmarks established by DORA research:
- Elite — Top-tier performance. You're in the top bracket of engineering teams globally.
- High — Strong performance. You're ahead of most teams but have room to improve.
- Medium — Average performance. There are clear areas for improvement.
- Low — Below average. These metrics highlight where your delivery pipeline needs attention.
The scorecard gives you an at-a-glance view: four cards, four metrics, four levels. Each card shows the current value, the performance level with a color indicator, and a brief explanation of what that level means. You don't need to memorize DORA benchmarks — the scorecard interprets the numbers for you.
An overall performance level is computed from the combination of all four metrics. If three of your metrics are Elite and one is High, you're performing at an Elite level overall.
Trend Charts: Direction Matters More Than Position
A single snapshot of DORA metrics tells you where you are. A trend tells you where you're going. The DORA dashboard includes trend charts that plot each metric over time, so you can see whether things are improving, stable, or degrading.
Select a time period — 7 days, 30 days, 90 days, or a custom range — and the trend chart shows your trajectory. Deployment frequency might be climbing steadily. Lead time might have spiked after a big refactor but is now recovering. Change failure rate might be flat at a healthy level.
Trends are what turn metrics from a performance review tool into a continuous improvement tool. You don't check DORA once a quarter and file it in a report. You watch the trends weekly, notice when lead time creeps up, and investigate before it becomes a problem.
Scoped to Your Architecture
Because Archyl knows your C4 model, DORA metrics aren't limited to project-wide aggregates. You can scope metrics to a specific system or container.
Want to know the deployment frequency of just the Payment Gateway? Filter by that system. Curious whether the Notification Service has a higher change failure rate than the Account API? Compare them side by side.
This is where architecture-aware metrics become genuinely useful. A project-wide MTTR of two hours might sound great — until you realize the API Gateway restores in 15 minutes and the Billing Service takes 18 hours. Scoped metrics surface the outliers that averages hide.
Organization-Wide DORA Overview
For engineering leaders managing multiple projects, the organization-level DORA overview provides a bird's-eye view across every project in the workspace.
The overview shows a summary bar with the aggregate performance level, then a grid of project cards — each displaying the four DORA metrics with their individual levels. You can immediately spot which projects are performing at an Elite level and which are struggling.
This isn't about ranking teams against each other. It's about identifying where to invest. If one project's lead time is climbing while others are stable, that's a signal worth investigating. If change failure rate is high across the board, maybe the issue is systemic — shared infrastructure, testing gaps, or deployment tooling.
The organization view uses the same period selector as the project view, so you can align timeframes when comparing across projects.
The Feedback Loop
DORA metrics work best as part of a feedback loop. Here's how we've seen teams use them effectively:
Set up release tracking — Connect your CI/CD pipeline to Archyl using GitHub Actions, webhooks, or the REST API. Releases start flowing in automatically.
Establish a baseline — After a few weeks of data, check your DORA scorecard. This is where you are today. Don't judge it — just note it.
Watch the trends — Check weekly. Are metrics moving in the right direction? Stable is fine. Degrading is a signal.
Investigate anomalies — When a metric shifts, scope it to individual systems. Often, a project-wide change is driven by one or two services.
Iterate — Make changes to your delivery process and watch the metrics respond. Faster code reviews reduce lead time. Better test coverage reduces change failure rate. Feature flags reduce MTTR.
The key insight from DORA research is that these metrics are outcomes, not goals. You don't improve deployment frequency by deploying more — you improve it by removing the friction that makes deploying slow or risky. The metrics tell you whether your process improvements are actually working.
Connecting the Dots
DORA metrics are the latest piece in Archyl's approach to architecture documentation that reflects reality, not just intent.
Your C4 diagrams show the structure. API Contracts show the interfaces. ADRs show the decisions. Release Management shows what shipped. And now DORA metrics show how well your delivery machine is running.
Each layer adds context to the one before it. A system on your diagram isn't just a box with an arrow anymore — it's a service with a defined API, documented decisions behind its design, a deployment history, and measurable delivery performance. That's the difference between a diagram and a living architecture platform.
Getting Started
If you're already tracking releases in Archyl, DORA metrics are available now. Navigate to your project's Releases page and switch to the Metrics tab. Your scorecard and trend charts are already populated.
If you haven't set up release tracking yet, start there. Follow the Release Management guide to connect your CI/CD pipeline, then come back to the Metrics tab once you have a few weeks of deployment data.
For organization-level insights, open the Releases page without selecting a specific project and switch to the Metrics tab. The overview will show all projects in your workspace with their individual DORA scores.
Your architecture knows what exists. Your releases know what shipped. Now your metrics know how well you're delivering.
Learn more about tracking deployments in Release Management, or explore how Architecture Change Requests bring structured review workflows to your C4 model.