DORA metrics calculator

How it works

Edit any input on the left. The tier panel on the right re-computes instantly. The composite tier is set by your weakest dimension— DORA's honest framing: your delivery is bounded by your worst metric, not the average.

No signup. No tracking. Pure client-side; nothing leaves your browser.

About the DORA tiers

The DORA (DevOps Research and Assessment) metrics are the industry-standard measure of software delivery performance, tracked annually since 2014 in the State of DevOps report (now Google Cloud's DORA report).

• EliteTop performers across all four dimensions. Multiple deploys per day, sub-hour MTTR, ≤5% change failure rate. Typically requires trunk-based development, CI/CD, feature flags, and disciplined runbooks.
• HighHealthy delivery cadence. Weekly to monthly deploys, same-day MTTR, 6-10% failure rate. Most successful product engineering teams sit here.
• MediumReasonable but constrained. Monthly to every-6-month deploys, multi-day MTTR, 11-15% failure rate. Often enterprise environments with heavy QA or change approval boards.
• LowOperationally fragile. Less than 2 deploys per year, multi-week MTTR, >15% failure rate. Common in legacy systems where releases are project-scale events.

For the deeper framework — how to improve each dimension and the pitfalls of optimising one at the expense of others — read the DORA metrics glossary entry.

Common pitfalls when measuring DORA

The DORA metrics look simple on paper. In practice, teams consistently game them — sometimes intentionally, sometimes by accident through bad instrumentation. The four anti-patterns below show up in roughly 80% of first-time DORA implementations we've seen.

1. 1. Counting CI/CD pipeline runs as “deployments”

   Pipelines that deploy preview environments, internal tools, or non-production environments inflate the deployment-frequency number without representing real delivery to customers. The honest measure is “deployments that reach the production user base” — and for teams running progressive rollouts, the count starts when the rollout reaches >50% of users, not when the artifact is published to the registry.

2. 2. Measuring lead time from PR open instead of commit

   DORA defines lead time as commit-to-production — including the time a feature sat in a branch before the PR was opened. Teams that measure from PR-open systematically under-report by 1-7 days. The fix is to read the first-commit timestamp on the feature branch, not the PR creation event. Tools that conflate these two systematically score teams as one tier higher than reality.

3. 3. Confusing MTTR with mean-time-between-failures

   MTTR (Mean Time To Restore) measures how quickly you recover once an incident starts. It does NOT measure how often incidents happen — that's mean-time-between-failures (MTBF), a different metric with different dynamics. A team with monthly outages that restore in 20 minutes scores Elite on MTTR; a team with weekly outages that restore in 18 minutes scores Elite faster. Both have very different reliability postures. Always pair MTTR with incident frequency when reporting upward.

4. 4. Defining “change failure” too narrowly

   DORA's definition of a change failure is broader than most teams realise: any deploy that requires immediate remediation (hotfix, rollback, forward-fix within the same business day). Teams that only count rollbacks under-report change failure rate by 50-80%. The honest measure includes hotfixes within 4 hours, manual config patches to mitigate prod bugs, and feature-flag flips that disable broken functionality. If your CFR is sub-5% on a fast-moving product, you're probably under-counting.

The composite tier you compute above is only as good as the inputs. Before sharing the number with leadership, audit your instrumentation against the four pitfalls above. Most teams discover they were a tier higher than reality on first measurement.