What are DORA metrics and how do you calculate them?

DORA metrics, not the EU DORA regulation

Audience: an engineering leader adopting or interpreting DORA metrics for a delivery team or organization. This page covers the DevOps Research and Assessment (DORA) program's software-delivery metrics — not Regulation (EU) 2022/2554, the Digital Operational Resilience Act for financial entities. They share the acronym DORA and nothing else. The dora-incident-reporting guide on this site is the EU regulation page under breach reporting. Last verified 10 September 2026. Not legal advice.

• DevOps DORA: deployment frequency, lead time for changes, change failure rate, time to restore service — industry research metrics from dora.dev and the State of DevOps reports.
• EU DORA: ICT risk management and incident reporting for in-scope financial entities — a legal requirement only if it applies to your organization.
• This page does not determine that EU DORA applies to you and does not file regulatory reports.

Precise definitions — DORA research program (State of DevOps 2024)

The definitions below follow the DORA research program as published on dora.dev and in the Google Cloud State of DevOps Report 2024. Recent reports refer to time to restore as failed deployment recovery time; the underlying measure is recovery after a failed change. A fifth operational signal, reliability, appears in recent reports as an additional lens on operational performance.

Worked calculation — deployment frequency

Example (illustrative, not YOUR data): count successful production deployments in a rolling 28-day window. Numerator: 14 successful production deploys. Denominator: 28 days. Deployment frequency = 14 deploys per 28 days, expressible as roughly one deploy every two days or 0.5 deploys per day depending on how you report it.

The definitional choice that matters: only successful production deployments count. Preview, staging, and failed deploy attempts are excluded in an honest implementation. Bot-driven dependency releases may or may not count — record the rule.

Worked calculation — lead time for changes

Example (illustrative): a change is committed at 09:00 Monday and runs successfully in production at 15:00 Thursday the same week. Lead time = 78 hours from commit timestamp to production success timestamp for that change.

Aggregate by taking the median (or another chosen percentile) across changes in the window. Median resists outlier branches; mean does not. The DORA survey historically asks organizations for their typical experience — a derived median from system timestamps is comparable only if you document the clock start (commit, merge, or PR open).

Worked calculation — change failure rate

Example (illustrative): in a 28-day window there are 20 successful production deployments. 2 of those deployments required remediation (rollback, hotfix, or patch) because they degraded service. Change failure rate = 2 divided by 20 = 0.10 = 10%.

The definitional choices: what counts as a failure (incident ticket, rollback event, or customer-impacting alert), and how failures are attributed to a specific deployment. Automatic attribution rules should be disclosed before you trust the trend.

Worked calculation — failed deployment recovery time

Example (illustrative): a deployment at 14:00 causes a production incident. Service is restored at 16:30 the same day. Recovery time = 2.5 hours for that incident.

Aggregate by median or another percentile across qualifying incidents in the window. The clock start matters: first alert, first human acknowledgement, or confirmed customer impact — pick one and keep it constant. Recent DORA materials use the term failed deployment recovery time for this measure.

Benchmark tiers shift yearly — guidance, not standards

The DORA research program publishes performance clusters (historically elite, high, medium, low) in annual State of DevOps reports. The band boundaries and labels change as the survey sample changes. They are orientation from cross-industry survey research, not auditable standards and not targets to paste onto derived telemetry without checking definitions.

Comparing your system-derived numbers to survey benchmarks is only meaningful when you understand that survey respondents used their own internal definitions. A derived median lead time from commit-to-production timestamps is not automatically comparable to a survey answer about typical lead time.

• Treat benchmarks as context, not compliance thresholds.
• Prefer your own trend under a fixed definition over chasing a moving band.
• Hold definitions constant when comparing quarter to quarter.
• Disclose production-only filtering, bot exclusion, and repository coverage.

Legal requirement versus research guidance versus SRM recommendation

DORA delivery metrics are industry research guidance — not legal requirements. EU DORA (Regulation (EU) 2022/2554) is a legal requirement only if it applies to your organization as a financial entity. ShipReady Metrics computes Delivery Health from connected sources using SRM's production-only filtering and coverage gates — an SRM recommendation documented on /methodology, not a DORA certification.

What you need to do now

As of last verification on 10 September 2026, the list below is operational preparation. Not legal advice.

• Confirm you are discussing DevOps DORA metrics, not EU DORA incident reporting.
• Write down numerators, denominators, windows, and production-only rules for each metric.
• Instrument from deployment and version-control events; avoid survey-only collection for steering.
• Leave a metric Not measured when data is too thin rather than estimating it.
• The dora-metrics glossary on this site is the short definitions page. The dora-metrics-without-spreadsheets learn guide on this site is the instrumentation guide. The measure-engineering-excellence guide on this site is the balanced scorecard page.

Checklist

Question list for engineering leaders — not a certification and not legal advice.

• Are we measuring DevOps DORA, not EU DORA?
• Is each metric defined (numerator, denominator, window) before we publish it?
• Are production deploys separated from preview, staging, and CI noise?
• Do we pair throughput metrics with stability metrics in the same review?
• Are benchmark tiers treated as guidance, not standards?
• Can we trace each number back to source events?

Where this shows up in ShipReady Metrics

Signed-in Delivery Health (/scores/delivery-health) computes deployment frequency, lead time for changes, and change failure rate from connected CI and deployment sources using production-only filtering. Metrics without observable signal read Not measured.

Mean time to restore appears when an incident or operations source is connected; otherwise it is honestly omitted rather than inferred from commit history.

Repository scope (signed-in Integrations → repository scope) controls which repositories feed delivery metrics. Scope affects engineering scores, not Compliance allowlists.

The public DORA metrics calculator at /tools/dora-metrics is a self-assessment worksheet — not connected telemetry. This product does not certify DORA performance tiers.

Primary sources (last verified 10 September 2026)

Every definitional claim on this page is taken from one of these.

dora.dev — DORA research program metric definitions and capabilities model — industry research guidance.

Accelerate: The Science of Lean Software and DevOps (Forsgren, Humble, Kim; IT Revolution Press, 2018) — industry research.

Google Cloud State of DevOps Report 2024 — annual survey and metric guidance; benchmark tiers are survey-derived and change year to year.

Regulation (EU) 2022/2554 (Digital Operational Resilience Act) — a different instrument; legal requirement only if it applies. Not the subject of this page.

ShipReady Metrics /methodology and /what-we-measure — vendor documentation for how SRM computes Delivery Health. SRM recommendation, not a DORA program endorsement. Not legal advice.

Frequently asked questions