Delivery (DORA)
Can this team ship the plan?
A value-creation plan assumes the team can deliver it. CodeDD measures how often and how reliably every connected repository ships to production, and keeps those numbers current after close.
Throughput
Deployment frequency
4.2 / week
54 deploys
Lead time for changes
23.6h
P90 3.9d · 54 deploys
−1.3h vs last week
Failed deployment recovery
3.5h
5 recoveries
Instability
Change fail rate
8.2%
4 of 49 planned deploys
Deployment rework rate
9.3%
4 hotfixes · 1 rollback of 54
Trusted by
What DORA measures
The industry standard for software delivery.
DORA (DevOps Research and Assessment) is Google Cloud's long-running research programme on software delivery. Its metrics rate how fast and how reliably a team ships, in four bands from Elite to Low.
Throughput
Deployment frequencyEliteSeveral a dayHighDaily to weeklyMediumWeekly to monthlyLowUnder monthlyLead time for changesEliteUnder 1 dayHigh1 day to 1 weekMedium1 week to 1 monthLowOver 1 monthFailed deployment recoveryEliteUnder 1 hourHighUnder 1 dayMedium1 day to 1 weekLowOver 1 weekInstability
Change fail rateEliteUp to 5%HighUp to 10%MediumUp to 15%LowOver 15%Rework rate, the fifth metric, has reference bands only.
Objective delivery data
Objective data for every delivery discussion.
CodeDD collects delivery data automatically from the pipelines, so you and management review the same numbers: how often the team ships, how long a change takes to reach customers, and how often a release needs a fix.
Measured from the pipelines
Deploys, pipelines, and pull requests come straight from GitHub, GitLab, Azure DevOps, or Bitbucket.
All five DORA metrics, rated
Throughput (frequency, lead time, recovery) and instability (change fail, rework), each rated on the DORA research bands.
Current after close
Automated syncing keeps the numbers up to date, so the hold-period view always reflects how the team ships today.
Across the investment cycle
What delivery data tells you.
Pre-deal tech DD
Test management's delivery story against evidence before you underwrite a plan that depends on it.
Hold period
Watch delivery month by month as the plan lands, and spot the repository that starts to slow it down.
Pre-sale preparation
Show buyers current, measured delivery performance and the direction it is moving.
Regular cadence
Delivery speed and quality.
Production deploys split into planned releases, hotfixes, and rollbacks, next to lead time against the Elite band. A rising hotfix share is the early sign of a team shipping faster than it can test.
Deploy volume · per week
Lead time · weekly median
Dashed line: Elite ≤ 1 day. Point colour is that week's band.
By repository
Find where instability comes from.
Each repository gets its own DORA tier. In this example, billing-api ships most often and accounts for every failed deploy, while partner-portal releases less often and rates Medium.
| Repository | Tier | Deploys | Lead time | Change fail |
|---|---|---|---|---|
| billing-apiGitHub | High | 3.0/wk | 21.4h | 11.8% |
| cube-command-centerGitHub | High | 0.7/wk | 30.1h | 0.0% |
| partner-portalGitLab | Medium | 0.5/wk | 96.4h | 0.0% |
Across the portfolio
See which portfolio companies can ship their plan.
The four key DORA metrics for every company, on the same definitions and the same 90-day window. Company C deploys almost as often as Company A, but one release in four needs a fix, so its speed is costing it stability.
Portfolio delivery (DORA)
Last 90 days · five portfolio companies| Metric | Company A | Company B | Company C | Company D | Company E |
|---|---|---|---|---|---|
| Throughput | |||||
| Deployment frequencydeploys per week | 11.5 | 4.2 | 9.8 | 0.2 | 0.6 |
| Lead time for changeshours | 9.5 | 23.6 | 14 | 910 | 210 |
| Failed deployment recoveryhours | 0.8 | 3.5 | 31 | 190 | 20 |
| Instability | |||||
| Change fail rateshare of deploys needing a fix | 3.1% | 8.2% | 27% | 12% | 6.5% |
Connect your Git host
GitHub
GitLab
Azure DevOps
Bitbucket
For the portco teams
Fast to set up. Clear about what it measures.
Connected in minutes
The portco grants read-only access to its Git host, and that's the whole setup. No agent to install, no survey, no reports.
Measures delivery, not developers
It looks at repositories and pipelines. It does not score or rank individual engineers.
One shared view
You and the portco CTO see the same data, so operating reviews start from the same facts.
Low is not always bad
If customers install the software themselves, a team may release only quarterly and rate Low. That can be exactly right for the business.
FAQ
Questions.
Which metrics do you show?
The five-metric DORA model, in two groups. Throughput: deployment frequency, lead time for changes, and failed deployment recovery time. Instability: change fail rate and deployment rework rate. Each is rated Elite, High, Medium, or Low on the DORA research bands — except rework, which shows reference bands only, since the research does not rate it as performance. The overall tier averages the metrics that have enough data.
How are change fail rate and rework rate different?
Change fail rate is the share of planned production deploys whose next successful deploy was a hotfix or rollback within seven days — how often a release breaks. Rework rate is the share of all successful production deploys that were hotfixes or rollbacks — how much delivery capacity goes into fixing what shipped.
Why do some numbers show as unknown or limited?
Each metric needs a minimum number of events in the window. A repository with too few deploys is shown as Unknown or marked limited instead of being scored — so a thin sample is never presented as a strong result. Widening the window from 30 to 90 days usually resolves it.
How is the overall number calculated?
Deploy events are pooled across every repository that reports them — not averaged per repository — so a busy service and a quiet one each count for what they ship. Filter to a single repository to see its own numbers.
How current is it?
Delivery data syncs from Git every day, and the view shows when it last synced. Anything older than 48 hours is flagged as stale.
What access does it need?
A read connection to GitHub, GitLab, Azure DevOps, or Bitbucket. Pipelines come from GitHub Actions, GitLab CI, Bitbucket Pipelines, and Azure DevOps builds. You choose which environment counts as production.
How is this different from Development activity?
Delivery measures how often and how safely the team ships. Development activity shows what that effort goes into — new product or keeping legacy systems alive. A team can ship smoothly and still spend most of its time on maintenance.
What data do you store?
Delivery events — deploys, pipeline outcomes, environments, timestamps — and the metrics derived from them. Not source code.
See how a team you are evaluating actually ships.
Connect a repository yourself, or book a walkthrough of the five metrics, the weekly trend, and where instability comes from.