Change failure

Define the event clearly

Not every rollback is a failure, and not every failure produces a formal incident. A team might count a change when it causes customer impact, requires an emergency fix, or must be reverted. The choice should match the service and the question being asked.

Record the deployment identifier, affected service, impact window, and recovery action. These details let teams connect an operational event to the change that preceded it without guessing from timestamps alone.

Learn from the path to failure

A failure can result from code, configuration, data, dependencies, infrastructure, or a missing safeguard. Review the full path: what was changed, how it was tested, who reviewed it, and how the system detected the problem.

The goal is a stronger system. Useful responses may include better tests, safer rollout controls, clearer ownership, improved alerts, or smaller deployment batches. Blaming an individual rarely addresses the conditions that allowed the failure.

Connect it to delivery measures

Change failure rate summarizes how often changes create operational trouble. Recovery time describes how quickly service is restored. Read both with deployment frequency and lead time to understand speed and stability together.

Weave can add engineering context to that review by showing patterns in pull requests, review effort, and rework around affected changes.