Change Failure Rate
Also known as: Deployment Failure Rate, Release Failure Rate
Definition
Change failure rate is one of the four DORA metrics. It measures how often production changes create failure. For a board or buyer, the metric matters because it converts engineering process quality into customer risk, support load, roadmap delay, and avoidable EBITDA drag.
A high change failure rate is not just an engineering problem. It signals weak testing, unclear ownership, brittle architecture, poor release governance, or insufficient observability.
In technical diligence, the number matters less than the trend and the response system. A team that fails rarely but cannot restore quickly can still create board-level risk.
Related terms
- DORA Metrics — Four software-delivery metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service.
- SOC 2 — A controls attestation for security, availability, confidentiality, processing integrity, and privacy. Often required for enterprise software sales and diligence.
- Technical Debt — The cumulative cost of architectural, platform, testing, and operational shortcuts in software systems — convertible to dollar EBITDA drag and exit-multiple turns.
Where this gets applied
- Project Recovery — Stalled programs unblocked. We've rescued $13M and $3M Fortune 500 initiatives in under 30 days.
- Technical Debt — Quantification in dollars, not adjectives. Then a remediation plan that runs in parallel with delivery.
- Compliance & Security — SOC 2, CMMC, FedRAMP, security baselines for post-acquisition standardization.