DORA Metrics Calculator

Calculate your team DORA tier — Elite, High, Medium, or Low — for all four delivery metrics. No GitHub integration. Enter 30 or 90 days of data and get an actionable recommendation.

Want precise definitions and a step-by-step way to collect the data? Read our DORA metrics guide.

What DORA actually measures

DORA metrics measure delivery throughput (Deployment Frequency, Lead Time for Changes) and delivery stability (Change Failure Rate, Time to Restore Service). They don't directly measure code quality, developer happiness, or product-market fit. Use them to spot constraints in how software moves from change to production — not as a performance review score.

Overall tier = your lowest metric

The overall DORA profile is intentionally conservative: one Low metric makes the whole profile Low. That prevents teams from hiding fragile recovery behind high throughput. If your bottleneck is a stability metric (CFR or TTRS), fix it first — higher deployment frequency will otherwise amplify incidents and rework.

The 2024 stability paradox

In the 2024 DORA data, teams increasing deployment frequency sometimes see stability get worse before it gets better — especially Change Failure Rate. That doesn't mean you should stop improving throughput; it means your delivery system is being stress-tested. Watch trends over multiple measurement periods and invest in fast rollbacks, canaries, and production-like staging.

How to collect this data without tooling

You can estimate these metrics manually from your deploy logs and PR history. Our guide includes practical collection steps, GitHub CLI snippets, and common pitfalls (like counting preview deploys or ignoring rollbacks): read the DORA metrics guide. For official tier thresholds and research methodology, see dora.dev research.

Frequently asked questions

What is a good DORA score?▾

DORA defines four tiers: Elite, High, Medium, and Low. Elite teams deploy multiple times per day with lead times under one hour and fewer than 5% of deployments causing incidents. Most teams land in Medium — deploying weekly with lead times of days. The overall tier is your lowest single metric: one Low metric makes the whole profile Low, regardless of how other metrics perform.

How do I calculate Lead Time for Changes without a tool?▾

Pull merged PR timestamps using the GitHub CLI: gh pr list --state merged --json number,createdAt,mergedAt --limit 200. Lead Time starts at the first commit (use createdAt as a proxy if commit timestamps aren't available) and ends at production deployment. Average the results over your measurement period. For teams without feature branches, use the time between PR creation and merge as a starting approximation.

What counts as a "failed deployment" for Change Failure Rate?▾

A failed deployment is any production deployment that caused a service degradation, required a rollback, or necessitated a hotfix or emergency patch. CI/CD pipeline failures in staging or preview environments do not count — only production impact matters. If you're unsure whether an incident was deployment-related, check whether it started within 30 minutes of a deploy. Counting rollbacks is correct and intentional: they represent rework.

Our deployments are automated — does Deployment Frequency count canary or preview deployments?▾

Only count deployments that reach production (100% of traffic, or your final rollout stage). Canary releases at 1–5% traffic count once they complete full rollout. Preview deployments, staging, and test environments do not count. If you use progressive delivery (blue/green, canary), count the moment you reach full production traffic as a single deployment.

We have no incidents this period — does that mean our TTRS is Elite?▾

No. DORA's Time to Restore Service specifically measures incidents caused by software changes. If you had no incidents, toggle "No incidents this period" in the calculator — the metric is excluded from scoring rather than treated as Elite. A team with no incidents might have excellent stability, or might be under-deploying and thus avoiding exposure. Use Deployment Frequency as a signal for which is the case.