DORA metrics dashboard: the four keys, measured from real deployments
Updated
A DORA metrics dashboard shows the four keys of software delivery: deployment frequency, lead time for changes, change failure rate, and time to restore service. A trustworthy one calculates them from real production deployments, states its definitions, and shows a gap where data is missing.
Almost any tool can draw four charts. The difference between dashboards is in the definitions underneath: what counts as a deployment, which commits are excluded, and what the screen shows when a repository is not connected. This guide covers what each panel should contain, the ways a DORA dashboard misleads, how to evaluate one against your own repositories, and when a spreadsheet is still the right answer.
What a DORA metrics dashboard is for
The DORA research program identified four measures that together describe software delivery performance: two for throughput and two for stability. A dashboard exists to keep those four in front of the people who can change them, and to show the trend, because a single week of any delivery metric is mostly noise.
It serves two audiences with different needs. Engineering managers use it to find where work waits. Executives and boards use it as evidence that delivery is reliable. The second audience raises the bar: a number that will be repeated in a board pack has to be traceable to the deployments behind it.
The four panels, and what each must define
Every DORA dashboard shows the same four measures. What you are evaluating is the definition behind each one, which should be written down where a reader can find it.
| Metric | What the dashboard must define | How it gets inflated |
|---|---|---|
| Deployment frequency | What counts as a deployment, and to which environment. | Counting CI runs, preview builds, or merges as deployments. |
| Lead time for changes | The start and end events: first commit or merge, through to running in production. | Stopping the clock at merge, so the wait for release never appears. |
| Change failure rate | What marks a change as failed: a rollback, a hotfix, or a linked incident. | A denominator padded with automated dependency or bot commits. |
| Time to restore service | Which incident source supplies the start and end of an outage. | Incidents that were never logged, which makes recovery look instant. |
Four ways a DORA dashboard misleads
A DORA dashboard rarely fails by being empty. It fails by looking complete when it is not.
- Proxy events. If the tool has no deployment data, it may substitute merges or pipeline runs without saying so. The chart looks the same and measures something else.
- Silent gaps. A repository with no integration contributes nothing. If the dashboard averages over the connected ones only, it reports on the part of the estate that is easiest to measure.
- Blended estates. One figure across forty services hides the two that fail most. Ask for the per-service view and the coverage behind the headline.
- Individual ranking. DORA describes teams and systems. A dashboard that sorts engineers by these numbers invites gaming and loses the trust the data depends on.
How to evaluate a DORA dashboard
Evaluate on your own repositories. A demo runs on prepared data, where every definition question has already been answered in the vendor's favor.
- Ask for the written definition of each metric and compare it with how your team already counts.
- Pick one headline number and trace it back to the individual deployments behind it.
- Disconnect a source and watch whether the metric drops, shows a gap, or stays the same.
- Check whether bot and dependency-update commits are excluded, and whether you can see the exclusion rule.
- Ask what the tool reports when it has no incident source for time to restore service.
When a spreadsheet is enough
A small team with one service and one pipeline can track the four keys by hand, and should not buy software to avoid a monthly ten-minute task. The case for a dashboard starts when there are many repositories, more than one deployment path, or an outside audience that will ask how a number was produced.
DORA also has a limit worth stating. The four keys describe delivery flow. They say nothing about accumulated technical debt, security exposure, or whether the right thing is being built. Read them beside those signals, and treat any single metric optimized alone as a warning sign.
Where ShipReady Metrics fits
For fairness: ShipReady Metrics is our product, so read this as a vendor describing its own tool. ShipReady connects to GitHub, GitLab, AWS, Azure, and Supabase and expresses delivery as one of a set of 0-100 engineering scores, alongside security readiness, technical debt, cloud and agent health, IT modernization, and lifecycle. The delivery score is built on the DORA metrics. Deployment frequency, lead time for changes, and change failure rate are computed from real deployments, and CI runs, preview builds, and bot commits are excluded.
Two design choices follow from the evaluation list above. A dimension with no feeding data reads Not Measured, and coverage-gated confidence withholds the letter grade when a single thin source is all there is. And because delivery sits next to security and debt signals from the same connectors, a board reader sees the delivery number with its context. ShipReady measures teams and systems. It does not rank individual developers, and it is not a workflow or sprint-coaching tool.
Frequently asked questions
What are the four DORA metrics?
Deployment frequency, lead time for changes, change failure rate, and time to restore service. The first two describe throughput and the second two describe stability. They come from the DORA research program on software delivery performance and are meant to be read together, as a trend.
What data does a DORA metrics dashboard need?
Version control history, deployment events from the pipeline or hosting platform, and an incident source for failures and recovery. Without real deployment events a dashboard has to substitute a proxy such as merges, and without incident data it cannot honestly report time to restore service.
Is a DORA metrics dashboard related to the EU Digital Operational Resilience Act?
No. They share an acronym and nothing else. DORA metrics come from the DevOps Research and Assessment program and measure software delivery. The EU Digital Operational Resilience Act is a financial-sector regulation on ICT risk and incident reporting. A delivery dashboard does not address the regulation.
Can I build a DORA dashboard myself?
Yes, and for one service it is often the right choice. The four keys can be derived from version control and deployment logs with a script and a spreadsheet. A purchased dashboard earns its cost when there are many repositories, several deployment paths, or an auditor or board asking how each figure was calculated.
Should DORA metrics be used to evaluate individual engineers?
No. The metrics describe how a team and its systems deliver, and they are shaped by architecture, tooling, and process far more than by one person. Using them to rank individuals encourages gaming, such as splitting changes to raise deployment counts, and makes the data less reliable for everyone.
How does ShipReady Metrics calculate DORA metrics?
From real deployments. Deployment frequency, lead time for changes, and change failure rate exclude CI runs, preview builds, and bot commits, which can inflate a naive count. Where the platform has no data for a measure it reads Not Measured, and thin coverage withholds the letter grade.