Change failure rate
Change failure rate is the proportion of deployed software changes that cause failures requiring remediation, rollback, recovery, or other corrective action.
Effective Platform Engineering
Change failure rate is the proportion of software deployments that cause a failure requiring remediation, rollback, or another corrective action.
- How it is used
- Measures deployment reliability across environments and shows whether platform or application changes affect end users.
- How deep it goes
- Tracks failures from development through production and pairs the lagging percentage with leading quality and remediation indicators.
- Examples
- Uses development, QA, preview, and production environments plus Epetech’s quality, testing, and rollback measurements.
- What you can do after
- Evaluate deployment reliability, identify pipeline quality risks, and focus improvement where failures most threaten users.
Read how Effective Platform Engineering explains change failure rate →
Platform Engineering on Kubernetes
Change failure rate is the proportion of software deployments that require remediation because they cause failures or degradations in production.
- How it is used
- Uses change failure rate to evaluate delivery reliability and determine whether platform improvements support continuous delivery.
- How deep it goes
- Explains the metric’s role and a collection pipeline, but does not provide a detailed calculation formula or remediation policy.
- Examples
- Uses event sources, CloudEvents normalization, Knative Serving functions, PostgreSQL storage, and dashboards as pipeline components.
- What you can do after
- Calculate change failure rate by collecting, standardizing, storing, processing, and presenting delivery events.
Read how Platform Engineering on Kubernetes explains change failure rate →
Infrastructure as Code, Patterns and Practices: With examples in Python and Terraform
Change failure rate is the proportion of deployments or changes that require remediation, rollback, or other corrective action because they fail.
- How it is used
- Uses change failure rate to expose operational risk created by manual infrastructure configuration.
- How deep it goes
- Defines the metric and explains causes and mitigations, but does not provide a calculation method or reporting procedure.
- Examples
- Uses delayed database provisioning, routing and firewall tickets, and unaudited firewall changes as operational examples.
- What you can do after
- Apply it via infrastructure as code, automation, and testing to reduce failed changes and remediation effort.
Related concepts
- DORApart of · DORA is a research and measurement framework for software delivery performance, commonly using deployment frequency, lead time for changes, change failure rate, and time to restore service.
- test isolationproduced by · Test isolation is the property or practice of executing tests independently so their outcomes are not affected by other tests, shared state, dependencies, or external conditions.
- deployment frequencyused by · Deployment frequency is the rate at which software changes are deployed to a target environment, such as production.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.