Delivery (DORA)
Can this team ship the plan?
A value-creation plan assumes the team can deliver it. CodeDD measures how often and how safely the estate — every connected repository — ships to production, and keeps it 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
Beyond the management deck
A delivery claim is not delivery data.
Management can say the team ships weekly. The pipelines show whether it does, how long a change takes to reach customers, and how often it breaks.
Measured from the pipelines
Deploys, pipelines, and pull requests from GitHub, GitLab, Azure DevOps, or Bitbucket — not a questionnaire.
All five DORA metrics, rated
Throughput — frequency, lead time, recovery — and instability — change fail and rework — each rated on the DORA research bands.
Current after close
A daily sync keeps the numbers live, so the hold-period view is this week's — not the diligence snapshot.
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 week by week as the plan lands, and spot the repository that starts to slow it down.
Pre-sale preparation
Show a buyer a track record of shipping safely, not a claim in a slide.
Week by week
Speed, and what it costs.
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 carries its own tier. Here billing-api ships most often — and every failed deploy is its. A repository with no production deploys shows as Unknown, not as a score.
| Repository | Tier | Deploys | Lead time | Change fail |
|---|---|---|---|---|
| cube-command-centerGitHub | High | 1.2/wk | 30.1h | 0.0% |
| billing-apiGitHub | High | 3.0/wk | 21.4h | 11.8% |
| reports-svcGitLab · No prod deploys | Unknown | — | — | — |
Connect your Git host
GitHub
GitLab
Azure DevOps
Bitbucket
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 estate 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 estate 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.