Cut Firefighting While Raising Change Success Rates
The ticket queue fills before the change window closes. A patch that looked low risk took down a shared library. Payroll jobs stalled. Three teams opened bridges at once. Nobody planned a war room. The war room is the change, arriving as unplanned work.
Leaders often treat that night as a trade-off problem. Ship slower and fail less, or ship faster and absorb more firefighting. DORA’s own research says both metrics can improve together when teams stop approving changes on incomplete maps of what the change will touch.
Organizations cut firefighting while raising change success rates by building change management on an accurate, current CMDB that maps dependencies before a change is approved, not after it fails. Most firefighting is unplanned work triggered by changes that hit dependencies nobody mapped.
DORA’s 2016 State of DevOps research, conducted in partnership with Puppet in that era, set the baseline for this pattern. High performers spent 22% less time on unplanned work and rework, and 29% more time on new work. That pattern holds in current data too — Harness’s 2026 research (below) ties the same unplanned-work spike directly to unresolved dependency gaps under rising deployment volume. Firefighting volume and change failure rate sit on the same dependency gap. Close the gap and both numbers can move in the same direction.
Why firefighting and change failure are the same problem
Sourcegraph’s 2026 guide treats a change failure as a deployment that degrades service or forces remediation such as a rollback, hotfix, patch, or incident response. That is what ops teams label firefighting once the pager rings. The deployment is the cause. The bridge is the response. Counting them as separate goals hides the shared root.
Change failure rate is the share of production deployments that need that remediation. Firefighting is the labor that absorbs those failures, plus the secondary work they create across adjacent services. When a release breaks a dependency map nobody reviewed, the CFR numerator rises and the unplanned-work clock starts in the same minute.
DORA’s own taxonomy has a name for this pairing: deployment rework rate, the metric it added in 2024 to measure how much unplanned, reactive work each deployment failure generates. Change failure rate counts whether a deploy failed. Deployment rework rate counts what that failure costs afterward. Together they are two measurements of one dependency gap, not two competing goals.
Teams that see impact paths earlier fail less often after ship, so they spend fewer hours recovering. Throughput and stability can rise together when the approval path uses dependency truth instead of tribal memory.
Accurate dependency data lets a CAB or pipeline gate catch the failure path before approval instead of during incident response. Discovery-sourced CI relationships and service maps turn “what could this touch?” into a reviewable list rather than a hallway guess.
Are firefighting and change failure rate the same problem?
Yes in practice. Change failure rate counts deployments that need rollback, hotfix, or incident response, while firefighting is the unplanned labor that responds to those events — DORA’s deployment rework rate metric measures that labor directly. Both climb when changes ship without a current dependency map, so fixing visibility before approval, not adding process, moves both numbers together.
Where change approval actually breaks down
A change advisory board or an automated pipeline gate approves on a risk assessment. That assessment is only as strong as the inventory and relationship data behind it. If the CMDB is thin, stale, or missing cross-tier links, the form still looks complete. The approval still ships. The miss shows up in production.
Summaries of the 2025 DORA DevOps Report put the ideal change failure band near 0-2%, and note that only about 8.5% of teams report landing in that band. Most organizations live outside the ideal range even when they already invest in delivery tooling. The constraint is rarely a missing meeting. It is missing impact truth at decision time.
The same reporting stream highlights a counterintuitive pattern from recent DORA performance bands. Medium performers can show lower change failure rates (around 10%) than high performers (around 20%). DORA separates performers by deployment frequency and lead time as well as failure rate, so a higher band alone isn’t automatically worse — some high-throughput teams accept a higher failure rate as the cost of shipping far more often. The risk case is different: a team pushing more change without dependency-informed checks lands in a high-CFR band without the throughput gain to show for it, and that gap is exactly the firefighting load leaders hoped shipping culture would shrink.
Dependency-informed CMDB data belongs inside the approval decision itself. Change impact analysis should list downstream CIs and business services before the window opens. When service definitions are supplied, ViVID™ builds application-to-infrastructure maps teams can read in the same review, rather than reconstructing blast radius after the outage.
For the runtime picture behind those reviews, see Trusted Runtime Truth. For a closer look at wiring dependency data into the approval workflow itself, see CMDB for change management.
Why do change approvals still fail when CAB process looks mature?
Approvals inherit the quality of the CMDB and dependency map feeding the risk score. If relationships are incomplete or stale, the ticket can look low risk while shared libraries, data stores, or identity paths stay invisible. The failure appears after deploy as rollback work and multi-team bridges.
Reactive vs. dependency-informed change management
| Dimension | Reactive / tribal-knowledge approval | Dependency-informed approval |
|---|---|---|
| Approval basis | Ticket text, owner memory, last similar change, static checklist | Current CI record, discovered relationships, service map impact path, owner and environment tags |
| What gets missed | Shared platforms, silent consumers, cross-cloud links, identity and data-store edges outside the app team’s view | Fewer unknown edges; residual risk is documented gaps, not invisible ones |
| Result | Surprise degradation, hotfix thrash, bridge load, rising unplanned work | Earlier deferrals or scoped rollouts, lower change failure rate, more calendar time for planned work |
Every reactive miss in row two traces back to row one: a CAB can’t flag a consumer it was never shown. Dependency-informed approval moves discovery and relationship freshness upstream of the vote. A discovery-fed CMDB holds those relationships from multi-source discovery so impact analysis is not a spreadsheet exercise the night before the window. Keeping that data current is its own discipline; see CMDB automation for how discovery keeps records accurate without manual upkeep.
Integrations with ITSM platforms such as ServiceNow, Jira, Ivanti, HaloITSM, Xurrent, Hornbill, and TeamDynamix matter here only as delivery paths for the same CI and relationship truth. Keep the integration surface on one hub: all integrations.
What is dependency-informed change management?
It is change approval that uses a current CMDB and service dependency map to list what a change will touch before go-live. Compared with tribal checklists, it reduces unknown consumers, supports safer scoping, and lowers the share of releases that become incidents.
See how discovery-sourced CI relationships and change impact views feed CAB risk before the window opens, so firefighting and failed changes drop together.
What changes when the AI coding era raises deployment volume
AI-assisted coding raises how many changes a team can author in a sprint. Delivery systems that already struggled to map blast radius now face a higher change count against the same incomplete inventory. Holding change failure rate flat requires each change to be safer in proportion to the volume increase. Improving CFR while volume rises is a harder bar.
Harness’s State of DevOps Modernization Report 2026 frames AI’s impact as faster deployment pressure alongside rising incident and remediation load. On that public summary, very frequent AI coding tool users see about 22% of code deployments result in a rollback, hotfix, or customer-impacting incident. Recovery time on related production incidents runs longer too. Volume without stronger pre-change visibility converts coding speed into firefighting inventory.
That is why CMDB freshness and service mapping are rate limiters on how safely AI-accelerated delivery can land. High-frequency discovery cycles keep CI and relationship data close enough to runtime that CAB and pipeline gates review the estate you have, not the estate you had last quarter. Pair that with change risk views that surface downstream impact before the window, and the organization spends less night shift reconstructing what a commit touched. Teams need proportionally stronger pre-change impact data to hold CFR steady while throughput climbs.
Related reading on approval without tribal maps: CAB blast radius without tribal knowledge.
How does AI coding pressure change failure rate?
AI tools raise change volume. If dependency visibility stays weak, more deployments hit unknown consumers, so rollbacks and hotfixes rise even when individual commits look small. Teams need proportionally stronger pre-change impact data to hold CFR steady while throughput climbs.
Cut firefighting while raising change success rates
Stop budgeting firefighting and change success as opposite knobs. Treat them as two readouts of the same visibility gap. Put discovery-sourced CI relationships and service maps into the approval path. Measure CFR with a clear failure definition. Track unplanned work hours as the labor twin of that rate. When both improve, you did not buy slower delivery — you cut firefighting while raising change success rates by buying fewer surprises per deploy.
Frequently Asked Questions
Does reducing change failure rate mean deploying less often?
No. High-performing delivery research has long shown that strong practices can raise throughput while cutting failure and unplanned work. The constraint is not deploy count. It is whether each deploy is reviewed against real dependencies. Teams that map impact before approval can ship more often with fewer bridges, which is the opposite of slowing the pipeline to buy stability.
What is the actual definition of a failed change?
Use a practical production definition. Sourcegraph describes failure as degraded service or another production issue that needs remediation such as a rollback, hotfix, patch, or incident response. Many teams also count a forward-fix commit tied to the same release window. Minor non-user-impacting tweaks usually stay outside the failure bucket so CFR stays a reliability signal, not a noise metric.
How does a CMDB lower change failure rate?
A maintained CMDB stores configuration items and the relationships between them. Before approval, change impact analysis can list downstream systems and services that depend on the target CI. Reviewers defer, split, or add monitors when the map shows shared risk. Failures that would have appeared as firefighting after deploy get caught as scoped decisions before deploy, which lowers CFR and unplanned work together.
If your CAB still approves changes on narrative risk alone, schedule a working session on dependency-informed change with current maps in the room. Request a demo to walk change impact analysis on your estate pattern, not a generic slide path.
