DORA Metrics Analyzer

{{ summaryHeading }} {{ summaryPrimary }} {{ summaryLine }} {{ flowBadge }} {{ instabilityBadge }} {{ deploymentBadge }}

Deployment CSV:

Paste one production deployment per row, or browse/drop one CSV or TXT file. Source text stays out of the share URL.

{{ fileStatus || 'Drop one CSV or TXT file onto the textarea.' }}

Service or team:

The label appears in copied and downloaded review artifacts.

Measurement window:

{{ window_days }} days

Keep the same window when comparing this service over time.

days

Weekly cadence reference:

Use the same contextual reference across recurring service reviews.

Lead-time guardrail:

{{ lead_time_target_hours }} hr

Local review guardrail; the analyzer does not assign a universal grade.

Change-fail guardrail:

{{ cfr_target_pct }}%

Review the token policy before comparing periods.

Recovery guardrail:

{{ recovery_target_hours }} hr

Missing recovery timestamps remain an evidence gap rather than a fast result.

Rework guardrail:

{{ rework_target_pct }}%

Use stable rework labels across review periods.

Failure status tokens:

Default: failed, rollback, incident, hotfix, revert, outage.

Rework tokens:

Default: hotfix, rework, emergency, incident, patch, unplanned.

Metric	Current	Reference	Signal	Review note	Copy
{{ row.metric }}	{{ row.current }}	{{ row.reference }}	{{ row.signal }}	{{ row.note }}

Deployment	Deployed UTC	Lead time	Outcome	Recovery	Work type	Copy
{{ row.id }}	{{ row.deployed_at }}	{{ row.lead_label }}	{{ row.outcome }}	{{ row.recovery_label }}	{{ row.work_type }}

Priority	Signal	Evidence	Next action	Copy
{{ row.priority }}	{{ row.signal }}	{{ row.evidence }}	{{ row.next_action }}

{{ chartState.flow === 'loading' ? 'Loading weekly flow chart…' : 'Weekly flow chart unavailable. Check your connection, then retry. CSV remains available.' }}

{{ chartState.instability === 'loading' ? 'Loading weekly instability chart…' : 'Weekly instability chart unavailable. Check your connection, then retry. CSV remains available.' }}

A delivery review can look healthy for the wrong reason. Frequent releases may include a stream of emergency fixes, while a low failure rate may sit beside changes that wait days to reach production. DORA metrics keep speed, flow, recovery, and repair work separate so a team can see which part of delivery changed.

The current five-metric model divides software delivery performance into throughput and instability. Throughput covers how often changes reach production, how long they take to get there, and how long recovery takes after a failed deployment. Instability covers the share of deployments that need immediate intervention and the share devoted to unplanned incident-driven rework.

DORA metrics grouped by throughput and instability
Measure	Question it helps answer	Evidence needed
Deployment frequency	How often does this service reach production?	Deployment count and a defined reporting window
Change lead time	How long does committed work wait before production?	Commit and deployment timestamps
Failed deployment recovery time	How long does restoration take after a failed deployment?	Deployment and recovery timestamps for every failure being judged
Change fail rate	What share of deployments require immediate intervention?	A stable rule for classifying failures
Deployment rework rate	What share is unplanned work caused by a production incident?	A stable rule for classifying rework

Those measures become comparable only when the observation boundary stays steady. One service should not be mixed with unrelated applications, and a 30-day window should not be compared with another period whose deployment records or failure definitions were collected differently. Changes in timezones, incident labels, or what counts as production can move a number without changing the delivery system.

Medians summarize a typical duration, but they do not expose every slow change. A higher percentile can reveal a delayed tail that the median hides. Counts also need context: a rate based on a few deployments can swing sharply, and missing commit or recovery times reduce the evidence available for the duration measures.

DORA metrics are team-level improvement signals, not grades for individuals or universal targets for every service. They do not measure customer impact, product value, incident severity, or root cause. Their strongest use is a repeated review that keeps definitions stable, checks the source records, and connects a movement in the numbers to release, build, review, approval, rollback, or incident work.

How to Use This Tool:

Prepare one production-deployment history for one service, then choose comparison rules that can remain stable across later reviews.

Name the Service or team and set the Measurement window. The window is the denominator used to normalize deployment frequency to a weekly rate.
Paste or load the Deployment CSV. A valid deployment time admits a row. Commit time supplies lead-time evidence, while failed rows need recovery times at or after deployment to support the recovery metric.
Invalid deployment times skip their rows. Missing or reversed optional timestamps remain evidence gaps; they are never converted to zero-hour durations.
Choose a Weekly cadence reference and four guardrails. Use Trend only when no cadence threshold is justified. Change the failure or rework tokens under Advanced only when the source vocabulary requires it.
Read Metric scorecard beside Deployment evidence. Resolve skipped rows, duplicate IDs, and missing timestamps before using Improvement plan or the weekly views to choose a delivery constraint for follow-up.

Interpreting Results:

Start with evidence coverage, then read the five measures as a set. A faster or more frequent flow is not a complete improvement when failure, recovery, or rework worsens.

Compare median lead time with P85 lead time. A wide gap means a slower group of changes is hidden behind the typical value.
A duration guardrail is met at equality, and percentage maximums are also inclusive. Cadence passes when frequency equals or exceeds its selected reference.
Recovery passes only when there are no failures, or every failed row has usable recovery evidence and the median is within the guardrail.
Failure and rework depend on the configured substring tokens. Inspect matched rows before treating either rate as an operational fact.

Verify the deployment ledger against the release and incident systems of record. For trend comparisons, keep the service boundary, window, timestamp convention, token policy, and guardrails unchanged.

Technical Details:

Each usable row represents one production deployment. The deployment timestamp controls admission to the dataset; the other fields determine which duration samples and classifications that row contributes. Aggregation occurs only after timestamps and tokens have been normalized.

Formula Core

The service-level measures use valid deployment rows as the common population. Durations are elapsed hours, and rates are percentages of all accepted deployments.

\begin{array}{rcl} F & = & \frac{7 N}{W} \\ L_{i} & = & t_{deploy,i} - t_{commit,i} \\ CFR & = & \frac{N_{failed}}{N} \times 100 \\ R_{i} & = & t_{recovered,i} - t_{deploy,i} \\ RWR & = & \frac{N_{rework}}{N} \times 100 \end{array}

Symbols and aggregation rules for the five DORA measures
Symbol	Meaning	Aggregation
`N`	Accepted deployments	Count
`W`	Measurement window in days	Used to produce deployments per week
`L`_i	Commit-to-deployment hours for row `i`	Median; p85 is also reported by linear interpolation
`CFR`	Change fail rate	Failed rows divided by `N`
`R`_i	Deployment-to-recovery hours for a failed row	Median of usable recovery intervals
`RWR`	Deployment rework rate	Rework rows divided by `N`

For p85 lead time, sorted observations use position (n − 1) × 0.85; a fractional position is linearly interpolated between its neighboring values. Canonical aggregates are rounded to six decimal places. Displayed frequency uses two decimals, rates use one decimal, and durations switch among whole minutes, one-decimal hours, and one-decimal days.

Two accepted deployments in a 14-day window produce 1 deployment per week. Lead intervals of 2 and 4 hours have a 3-hour median and a 3.7-hour p85. If one row matches the failure tokens and one matches the rework tokens, both rates are 50%.

Transformation Core

CSV evidence follows an ordered path from source row to metric sample. This preserves incomplete evidence instead of silently manufacturing values.

Transformation from deployment CSV to metric evidence
Step	Rule	Consequence
Map columns	Recognize common aliases for ID, commit, deployment, status, recovery, and work type; otherwise use that positional order.	Quoted and unquoted CSV cells are accepted.
Normalize timestamps	Date-only values become midnight UTC; values without a zone are treated as UTC.	Intervals and Monday-start weekly buckets use one elapsed-time basis.
Admit deployment	A valid deployment time is mandatory.	Rows missing it are skipped; duplicate IDs remain and create a warning.
Build durations	Commit cannot be after deployment, and recovery cannot be before a failed deployment.	An invalid optional interval is excluded without removing the deployment from rate denominators.
Classify outcomes	Failure and rework tokens use case-insensitive substring matching across status plus work type.	A row may count in both categories.

Rule Core

Inclusive reference and evidence rules
Signal	Pass rule	Evidence condition
Deployment frequency	`F` ≥ 14, 1, or 0.25 per week for the selected reference	Trend only removes the threshold
Change lead time	Median `L` ≤ the selected hours	At least one usable lead interval
Change fail rate	`CFR` ≤ the selected percentage	Every accepted row remains in the denominator
Failed deployment recovery	Median `R` ≤ the selected hours	No failures, or usable recovery evidence for every failed row
Deployment rework rate	`RWR` ≤ the selected percentage	Every accepted row remains in the denominator

The combined flow signal requires both frequency and lead time to pass. The combined instability signal requires failure rate, recovery, and rework rate to pass. Empty token lists yield zero matches but produce warnings, so an apparently low rate still needs its classification policy checked.

Accepted boundaries

Accepted DORA analysis input boundaries
Input	Boundary
Measurement window	1 to 180 whole days
Lead and recovery guardrails	0 to 168 hours inclusive
Failure and rework guardrails	0% to 100% inclusive
Deployment history	Up to 1,048,576 characters and 5,000 rows plus a header
Failure and rework token lists	Up to 500 characters each

Limitations and Privacy Notes:

The analysis is only as reliable as its deployment history and classification policy. Treat the result as a review of supplied evidence, not as an independent source of release or incident truth.

Deployment text and selected files are processed in the browser and excluded from the share URL. Copied or downloaded artifacts can still reveal service names, timestamps, incident labels, and delivery history.
Substring tokens may be too broad or may miss local terminology. Review the rows they classify before comparing rates.
Skipped rows, retained duplicate IDs, and missing duration evidence can distort a small sample.
Chosen references are local guardrails, not official DORA performance grades or a basis for ranking unlike teams.

References:

DORA’s software delivery performance metrics, DORA, updated January 5, 2026.
A history of DORA’s software delivery metrics, DORA, updated January 2, 2026.