Platform
DORA metrics that tell you which stage to fix.
Four numbers and a banding are where most DORA tooling stops. Pacia adds the part that makes them actionable: lead time split into coding, pickup, review and merge-wait, so "we are slow" becomes "our pull requests wait nine hours before anyone opens them".
- Lead time for changes
- 29.6h · High
- Deployment frequency
- 4.1 / day · Elite
- Change failure rate
- 12% · High
- Time to restore service
- 4.1h · High
- Largest stage
- Pickup, 9.8h of 29.6h
The four keys, measured properly
Lead time for changes
How long a change takes from first commit to running in production, banded elite through low and trended. Broken into four stages so you can see where the time is spent rather than only that it was spent.
Deployment frequency
How often you successfully release to production, from deployment events rather than from a proxy like merges to main. Trended daily, weekly or monthly depending on the window you choose.
Change failure rate
The proportion of changes that caused a degradation requiring remediation. Uses your own defect and incident definitions, discovered and confirmed — never a guess at what counts as a failure.
Time to restore service
How long it takes to recover when a change does cause a problem. The metric that most reliably distinguishes teams that ship confidently from teams that ship carefully and slowly.
The breakdown is the part you can act on
A lead time of 29.6 hours is a fact. The same 29.6 hours split into four stages is a decision about what to change this quarter.
Where a 29.6-hour lead time actually goes
- Coding11.4h
First commit → PR opened · 39% of total
- Pickup9.8h
PR opened → first review starts · 33% of total
- Review6.1h
First review → approved · 21% of total
- Merge wait2.3h
Approved → merged and deployed · 7% of total
Pickup is dead time — nothing is happening, nobody is blocked on a decision, the change is simply waiting. It is the largest stage in most organisations the first time it is measured, and the cheapest one to fix.
What Pacia adds on top of the four numbers
Cycle time breakdown by stage
Average lead time split into coding, pickup, review and merge-wait. Pickup — the gap between a pull request opening and the first review starting — is the largest stage in most organisations and the one nobody is measuring.
Trends, not snapshots
All four metrics bucketed over time as small-multiple charts, with the bucket size chosen from the range length. "Are we improving" is a different question from "how are we doing", and it is the one leadership actually asks.
Elite / high / medium / low banding
Each metric is banded against the standard DORA performance levels, so a number has a meaning without you having to remember what good looks like.
Per-team scoping throughout
Every metric is computed for the team you are looking at, from that team’s repositories. Members see their own teams; owners and admins see the whole organisation.
Working agreement overlay
Where a team has set a threshold for a stage — reviews start within four hours, say — the DORA page shows what proportion of that team’s merged pull requests actually met it.
Computed on request, from source rows
DORA figures are computed on demand from the pull request and deployment tables rather than from a pre-aggregated cube, which is why every number can drill through to the work behind it.
DORA questions we get asked
Where does deployment data come from?
From deployment events recorded against your repositories, plus your CI check configuration. Pacia does not infer a deployment from a merge to the main branch by default, because for a large proportion of teams that is simply not what a deployment is.
How is change failure rate calculated without incident tooling?
From the defect and incident definitions you confirm during setup — your Jira site’s real defect issue types, link types and excluded resolutions. If you have not configured them, the metric shows as unconfigured rather than as zero.
Can we compare teams on DORA?
Yes, on identical definitions, which is the only way a comparison means anything. Contributor-level comparison is supported too, on the performance boards.
How far back do the trends go?
Up to 180 days are backfilled per repository at connection time, so trends exist from day one. History is retained for 24 months.