DORA numbers are only worth showing to a board if each one can be traced to real deployments and real failures. The previous version could not do that well enough: it averaged, it counted a failed CI job as a failed change, and it put teams into tiers the 2025 research no longer publishes. We rebuilt it.
One page, organised around a decision
DORA Metrics opens on an Overview:
- A verdict in one or two sentences, naming the worst service first — for example, "api fails 1 in 4 deploys…".
- A scorecard: one row per service, five metrics (deployment frequency, lead time, change fail rate, recovery time and rework rate), each with its DORA 2025 band and its change against the previous period. There is deliberately no blended company score; averaging a healthy service with a failing one hides both.
- What to do next: the top three actions.
Then Delivery (lead time and where it goes, batch size, deploy days, slowest changes), Stability (every failure, what fixed it and how long it took, plus open failures), Actions, Setup and Data health. Choose a 30, 90 or 180-day period, or a custom range.
Actions ranked by expected impact
Every action comes from a rule applied to your data, and each one carries:
- its evidence — links to the exact merge requests and deployments behind it;
- an estimated impact in real units, such as ≈ 23 h of lead time saved or ≈ 2 more deploys a week;
- a concrete next step, and the DORA capability it builds.
Typical actions: Set a same-day review target for this service, Promote the release branch more often, Roll back or ship the fix now. Your engineering leads get a ranked backlog rather than five numbers to argue about.
Numbers you can defend
- Medians, with p75 and p90, instead of averages that one outlier can drag.
- Failures are traced to the change that caused them. A revert blames the deployment that first shipped the reverted merge request; a hotfix blames the deployment it fixed on the same production target. Only a hotfix attributed by deploy order alone is limited to the seven days before it. Where a failure can only be attributed by deploy order, we show what share of failures that is.
- A failed deploy job is not a change failure. Nothing reached production. These are listed separately and not counted.
- Release trains are understood. When work flows through a release branch, the individual merge requests inside it count as the changes, and the time spent waiting on the branch is shown as its own Release-branch wait segment of lead time.
- Benchmarks follow the DORA 2025 survey's bands, with the survey's full wording in each tooltip, and comparisons read like Faster than 76% of teams. The DORA page has no Elite/High/Medium/Low tiers, because the 2025 report does not publish them.
- Too little data says so. With too few deployments or changes (fewer than five), or fewer than three failures for recovery time, a metric reads Too few to score, never zero.
No GitLab? Start from ClickUp
DORA can now be estimated from your ClickUp workflow. Confirm which statuses mean started, ready to release and in production (we suggest them from the last 180 days) and you get release cadence, lead time, recovery and rework. Change fail rate stays blank until there is a way to link a failure to its cause, because inventing it would be worse than leaving it empty.
With both sources connected, GitLab leads whenever it has enough releases to score. Source lets you switch to the workflow view, and a GitLab vs ClickUp comparison shows where your tickets and your deployments disagree — for example, tickets marked done hours after the code actually shipped.
Setup that explains itself
- Detection is suggested, then confirmed. For each project we propose how production deploys are recognised — GitLab environments, a deploy job, or pipelines — and you confirm it. A project can have several deploy jobs, for example one per region, each treated as its own production target, and a commit shipped to all of them counts as one release.
- Traceability shows how many deployments and changes link to a ClickUp task, and recommends a referencing convention based on what your teams already do, such as
#<task_id>in the MR title. We find task IDs anywhere in branches, titles, descriptions and commits, including ClickUp custom IDs. - Team ownership: assign each project to a team, so team-scoped readers see their own services in full.
- Sync now, an immediate sync when you enable a project, and live progress (Syncing from GitLab… 2 of 7 projects). The first sync reads 90 days of history.
- Data health lists anything that weakens the numbers: stale projects, low ClickUp coverage, task IDs that match no task, failed sync runs.
- Team self-assessment: the five DORA 2025 survey questions, about two minutes per person, answered by Admins and Managers and shown next to what the data says once a team has three answers. The gap between the two is often the most useful conversation in the whole page.
Security
GitLab URLs that point into private infrastructure are refused (self-hosted GitLab on a VPN is still supported). Access tokens never appear in logs. Team-scoped readers see merge request titles, branch names and task names only for their own teams' projects. All Setup changes are Admin-only, and changes to project settings, workflow roles, sync settings and credential rotation are recorded in the audit log.
What changed in your numbers compared with the previous DORA version is set out in the metric-change note.
DORA Metrics is included on the Enterprise plan. Talk to us for a walkthrough on your own GitLab data.