DORA metrics are the industry-standard measures of software delivery performance, popularized by Google's DevOps Research and Assessment program. Leanmote tracks all four out of the box on the Software Delivery Performance tab of the Performance Delivery dashboard.
The four DORA metrics
Deployment Frequency — how often you ship to production. A speed metric.
Lead Time for Changes — how long a change takes to reach production. Another speed metric.
Mean Time to Recovery (MTTR) — how quickly you restore service after an incident. A stability metric.
Change Failure Rate — what percentage of deployments cause incidents. A quality metric.
Read in pairs, the four metrics balance speed against stability. Improving one without breaking the other is the goal.
Why they matter
DORA's research correlates these four metrics with overall software-delivery performance and, indirectly, with business outcomes. Teams that score well on all four tend to ship faster and recover quicker than peers. Tracking them gives you a defensible, externally validated benchmark.
What Leanmote needs to calculate them
A source-control integration (GitHub, GitLab, Azure DevOps) is the only requirement. All four metrics are derived from your repositories:
Deployment Frequency — merged pull requests per day, or GitHub deployments per day if you enable that source (below).
Lead Time for Changes — time from first commit (or PR open, depending on your configured method) to merge.
Change Failure Rate — share of merged PRs that read as corrective work, or share of failed production deployments in deployment mode.
Mean Time to Recovery — time between a merged PR and the hotfix or revert that followed it in the same repository.
You do not need to connect an incident-management tool: Leanmote infers the failure and recovery signals from your repositories. That keeps all four metrics available from day one, at the cost of some precision — see each metric's article for exactly what is counted.
Two ways to count a deployment
By default Leanmote counts a merged pull request as a deployment. That's a close stand-in for teams that deploy on merge, and a loose one for teams that batch several merges into a scheduled release.
If you deploy through GitHub, the organization owner can count the deployments themselves instead, in Settings → Modules → Performance Delivery with Measure deployments from GitHub. Then:
Deployment Frequency counts GitHub production deployments.
Change Failure Rate counts production deployments that GitHub reports as failed.
Lead Time for Changes and Time to Restore stay merge-based — the switch does not affect them.
Enabling it backfills up to a year of deployment history automatically, with a short progress notice on the dashboard while it runs.
How to read DORA in a review
Look at Deployment Frequency first — direction over the last 4 weeks.
Pair it with Lead Time. Frequent deploys with rising lead time means batch sizes are growing.
Validate quality with Change Failure Rate. If speed climbs but failure rate climbs too, you're trading.
End with MTTR. A high failure rate is more tolerable when recovery is fast.
Before comparing periods, check whether the deployment source changed in between — the two sources are not interchangeable.
Related articles
Deployment Frequency
Lead Time for Changes
Mean Time to Recovery
Change Failure Rate
Performance Delivery dashboard