DORA Metrics Calculator (Lead Time & Fail Rate)

About the DORA Metrics Calculator (Lead Time & Fail Rate)

Open an export of your production deployments — a CSV, Excel or JSON file, such as the runs of a CI workflow or a deployments list — or paste a git log with your deploy tags, and get the delivery metrics DORA describes: deployment frequency, change lead time (median and 85th percentile), change fail rate, failed deployment recovery time and, when unplanned fixes are marked, deployment rework rate. Each comes with its definition and its performance level from DORA’s research, for the whole period, for every service and for every week or month, with trend charts and a comparison of two periods.

Columns of GitHub Actions, GitLab and Azure DevOps run and deployment exports are recognised, other files are mapped by their column names, and every status value is shown with what it counts as. Add an incidents list (start, end and the deployment or commit it came from) for failures and recoveries your CI does not see. Gaps in the data are listed instead of silently skewing the numbers: deployments without a commit time, commits that come after their deployment (usually a time-zone mismatch), incidents without an end, and rows that could not be read.

Everything is worked out in your browser; no file is uploaded. Without a pass the result is a free preview: the four headline values with their levels, every data check and the first rows of each table. The trend charts, the comparison, every row, the rework rate and the PDF, Markdown and CSV exports unlock with a Premium pass.

Common uses

• Measuring a team’s delivery performance for a retrospective or a quarterly review, from the CI history you already have.
• Checking whether a pipeline change — smaller batches, trunk-based development, faster reviews — moved lead time or fail rate, by comparing two periods.
• Finding which service drags the numbers down, with the per-service table.
• Preparing the numbers DORA’s Quick Check asks for.

The metrics, as DORA defines them

DORA’s guide lists five software delivery metrics (dora.dev, DORA’s software delivery performance metrics):

• Change lead time: the time it takes for a change to go from committed to version control to deployed in production. Here: from the first commit (or the merge, whichever column you map) of each deployment to the deployment, as a median and an 85th percentile.
• Deployment frequency: the number of deployments over a period. Here: production deployments per day over the whole calendar days of the period, also shown per week or month.
• Failed deployment recovery time: the time to recover from a deployment that fails and needs immediate intervention. Here: from the failed deployment (or the incident’s start, if you choose) to the linked incident’s end, else to the next successful deployment of the same service.
• Change fail rate: the share of deployments that need immediate intervention. Here: deployments with a failed status or a linked incident, over all deployments.
• Deployment rework rate: the share of deployments that are unplanned and made because of an incident in production. Here: deployments whose type is one of the values you list (hotfix, rollback …), or whose title says hotfix, revert or rollback if you turn that on.

The first three measure throughput, the last two instability.

The performance levels

DORA’s 2024 Accelerate State of DevOps Report found four clusters in its survey (the 2024 report, page 13):

• Elite: lead time under a day, deploys on demand (multiple a day), 5 % change fail rate, recovery under an hour.
• High: lead time between a day and a week, deploys between daily and weekly, 20 % fail rate, recovery under a day.
• Medium: lead time between a week and a month, deploys between weekly and monthly, 10 % fail rate, recovery under a day.
• Low: lead time between a month and six months, deploys between monthly and every six months, 40 % fail rate, recovery between a week and a month.

The page places each metric on its own: an average of at least one deployment a day is elite, at least one a week high, at least one a month medium and at least one every six months low; lead and recovery times by their medians against the ranges above (a recovery of one day to a week sits between the medium and low levels, which do not cover it); and a change fail rate by the level with the smallest typical rate at or above it (up to 5 % elite, 10 % medium, 20 % high, 40 % low). DORA formed its clusters from all four metrics together, so a team’s overall level is not the worst or the best of its four.

Getting the data out of your CI

• GitHub Actions: the REST API’s workflow runs list (GET /repos/{owner}/{repo}/actions/runs, the workflow_runs response) has each run’s conclusion, times and head commit time; gh run list --json conclusion,createdAt,databaseId,headSha,name,status,updatedAt,workflowName works too, without commit times (GitHub REST API, gh run list). Keep only the workflow that deploys.
• GitLab: the Deployments API (GET /projects/:id/deployments) has the environment, the status and the deployed commit with its time (GitLab Deployments API).
• Azure DevOps: the Builds API, the Pipelines Runs API or the Release deployments API (Builds – List); builds and runs carry no commit time, so add one or use the git history for lead time.

Save the API’s JSON response as a file and open it here; nested fields become columns such as head_commit.timestamp.

Time zones and data checks

Times with a zone (2026-03-02T10:15:00Z, +05:30) are exact. Times without one are read as UTC or as this device’s zone, as you choose, and the page counts them: a mix of both in one file is the commonest cause of negative or inflated lead times. Weeks are ISO weeks starting on Monday. Every row that cannot be used is counted and named — unreadable times, statuses that are not deployments, repeated deployment ids, deployments without a commit time, commits after their deployment, incidents without an end or linked to nothing — with the first rows to look at.

Limitations

• The numbers are only as good as the export: a deployment that never reached production, or a failure nobody recorded, changes them. Read the data checks first.
• Change fail rate needs failed statuses or incidents; recovery time needs failed deployments followed by a fix or an incident with an end. Without them those metrics show “Not enough data”.
• Lead time from a CI export uses one commit time per deployment (the head commit or the merge); the git history mode can use every commit.
• The git history mode assumes a branch read with --first-parent, where each deploy tag closes the commits since the previous one.
• Up to 200,000 rows a file; the deployments table lists the newest 500 and the CSV export has all of them.

Privacy

On this device: nothing is sent

Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.