Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Monitor five software delivery metrics for each application or service: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. Read them together as measures of throughput and instability, and compare a service with its own results over time—not against a universal quota or an unrelated team.
The five CI/CD metrics to track
DORA’s current software delivery framework groups its five metrics into throughput and instability. The definitions work across technology stacks, but DORA recommends measuring one application or service at a time so that the deployment and recovery events have a meaningful scope. See the DORA metrics guide.
| Dimension | Metric | What it measures |
|---|---|---|
| Throughput | Change lead time | Elapsed time from a code change being committed to version control until it is deployed successfully to production. |
| Throughput | Deployment frequency | How often the service is deployed to production, measured consistently as deployment events or as the time between deployments. |
| Throughput | Failed deployment recovery time | Time to recover from a deployment failure that requires immediate intervention. |
| Instability | Change fail rate | The proportion of production deployments that require immediate intervention after deployment, commonly a rollback or hotfix. |
| Instability | Deployment rework rate | The proportion of deployments that were unplanned and made in response to a production incident. |
Throughput: how changes move and recover
Change lead time and deployment frequency show how changes flow from code to production. Failed deployment recovery time adds an important stability dimension to that flow: it covers recovery from a deployment failure requiring immediate action, not every kind of incident or outage recovery.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Instability: how often production needs intervention
Change fail rate captures the share of deployments that need immediate intervention. Deployment rework rate is narrower in a different way: it tracks unplanned deployments prompted by production incidents. Keeping both helps distinguish a failed deployment from subsequent production-driven rework.
#1 Best Overall
Define the events before calculating a metric
Metric names alone do not make dashboards comparable. Write down the start and stop events and what counts as production, a deployment, a failure, immediate intervention, and unplanned remediation. Apply the same definitions throughout the period you are comparing.
Lead time can mean different intervals
DORA’s change lead time runs from code commit to successful production deployment. It is not the same as a work-item lead time or cycle time. Azure DevOps defines work-item lead time as the interval from item creation to completion, while cycle time starts when the item first enters In Progress and ends at completion. Those measures can help explain planning and development flow, but they answer different questions from code-to-production lead time. See Azure DevOps lead and cycle time documentation.
Deployment frequency depends on what counts as a deployment
Choose whether the dashboard counts every production deployment event or deployment days, and state the production target and reporting window. A tool-specific example makes the distinction clear: Google Cloud Deploy documents metrics per delivery pipeline and production target over a rolling 30-day period. Its deployments metric counts successful and failed deployments, while deployment frequency is based on deployment days—so four production deployments on one day count as one deployment day. Its deployment failure rate is failed deployments as a percentage of deployment attempts. These are Google Cloud Deploy’s implementation choices, not universal formulas. See Google Cloud Deploy metrics documentation.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Use trends to improve delivery, not to set quotas
- Choose one service. Decide which application or service the dashboard represents and identify its production deployment target.
- Agree on event boundaries. Define deployment, failure, immediate intervention, and unplanned remediation before collecting or comparing results.
- Establish a baseline. Track the five measures over time and review throughput alongside instability. DORA reports that speed and stability are correlated for most teams rather than being inherently opposed.
- Investigate friction with the team. Use changes in the metrics to prompt questions about the delivery process; do not use one number as a proxy for the entire system or rank unlike services as if their contexts were identical.
- Test changes in context. Smaller batches are a reasonable improvement hypothesis because they are easier to reason about, move through the process, and recover after a failure. Check the service’s own trends rather than assuming a universal target.
- Keep collection effort proportionate. Start with the data needed for a useful decision. Integrating many systems for precision may not justify the initial effort; source-available or commercial tools with prebuilt integrations can help when they fit the team’s needs.
DORA cautions that targets can invite gaming and that comparisons between unlike applications can mislead. Its stated aim is improvement over time, not competition between teams or organizations.
Why older CI/CD metric lists may differ
Older DORA material often describes four keys: deployment frequency, lead time for changes, mean time to recover (MTTR), and change fail rate. DORA narrowed and renamed recovery in 2023 as failed deployment recovery time, tying it specifically to impairment caused by a production change. In 2024, it added deployment rework rate to distinguish unplanned incident-driven deployments from the broader failure percentage. The current list therefore has five metrics. See DORA’s metrics guide and capabilities and metrics history.
Reliability remains important when assessing user outcomes and delivery performance, but DORA’s history page says the 2021 report’s label of reliability as a “fifth metric” was inaccurate in retrospect. Reliability is better treated as an operational performance measure, not as one of the current five software delivery metrics.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Make dashboard comparisons meaningful
Before comparing two tools, teams, or reporting periods, check whether they use the same:
Recommended Free Tools
- Application or service scope and production target
- Start and stop events, including what counts as a successful deployment
- Aggregation window
- Deployment-event or deployment-day counting method
- Failure and immediate-intervention definitions
- Method for identifying incident-driven, unplanned deployments
- Per-service data availability and integration effort
A metric can be calculated correctly by a platform and still differ from another platform’s number because the underlying boundaries differ. Treat platform definitions as part of the metric, not as an interchangeable display setting.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
