What is Change Failure Rate?
Definition
A high Change Failure Rate suggests that changes aren't being adequately tested, reviewed, or validated before they reach production, regardless of how fast or how often they're deploying. It's the metric most directly tied to quality rather than speed, and it's meant to be read alongside Deployment Frequency and Change Lead Time rather than in isolation, since a team could deploy fast and frequently while still shipping a high proportion of broken changes. For database changes, failures often look different from application failures: a schema change might succeed technically but break an application that depended on the old structure, which is why failure rate for database changes benefits from being tracked in coordination with the application changes deployed alongside them.
Why Change Failure Rate matters
Speed metrics alone can be misleading: a team that deploys constantly but breaks something every third release isn't actually delivering reliably, no matter how fast the pipeline runs. Change Failure Rate is the check against that failure mode, and it's usually the metric that gets the most attention from leadership, since it ties most directly to customer-facing incidents and outages, which are the visible, felt cost of a delivery process that isn't actually working well.
How Change Failure Rate is calculated
The rate is calculated as the percentage of deployments that require some form of remediation afterward, a rollback, a hotfix, or an emergency change, out of all deployments in a given period. For database changes, this depends on reliably capturing both when a deployment happened and whether it later triggered a rollback or an incident, which requires the deployment history and any subsequent remediation to be logged consistently rather than tracked separately in an incident management tool that doesn't connect back to the original change that caused it.
How Liquibase helps
Liquibase's Operation Reports and drift detection help identify when a deployed change caused an unexpected state, and rollback history is tracked in the same system as the original deployment, so a failure and the change that caused it stay connected in one record. Policy Checks reduce failure rate directly by catching a category of problems, missing rollbacks, unapproved destructive changes, before they ever reach production, rather than relying on failures to surface those issues after the fact. Tracking failure rate by author, team, or change type can also help target training or process improvements where they'll actually move the number, rather than applying a blanket fix to a problem that's concentrated in one specific area. A rate that improves right after introducing Policy Checks is a reasonably strong signal that manual review was missing the same categories of problems automated checks are now catching consistently.
