Change failure analysis

Analyze the system around the change

A failed deployment rarely has a single useful explanation. The change may contain a defect, but detection may have been delayed by a missing test, a noisy signal, an unclear ownership boundary, or a rollout policy. Analysis should ask how the system allowed the condition to reach production and how it can make the next response safer.

Capture the change identifier, service, deployment event, failure mode, detection time, user impact, response, recovery, and follow-up. Keep the distinction between a deployment that failed immediately and a deployment that later contributed to an incident. Those events may require different prevention work.

Look for patterns over time

One incident can produce a useful learning review, but a rate requires a consistent denominator. Compare failures by service, change type, rollout method, review path, and test coverage where those fields are reliable. Examine rework and recovery alongside change failure rate. A lower failure count may reflect less deployment activity rather than a safer path.

Avoid using failure analysis to rank individuals. The purpose is to improve the delivery system, strengthen feedback, and make recovery more predictable.

How Weave can help

Weave helps teams inspect the development work behind a failure and compare it with similar changes. That can reveal patterns worth testing, such as larger changes or a recurring review gap. The analysis is strongest when the team brings deployment, incident, and customer evidence into the same discussion.