Deployment rework rate

Count the response, not just the original failure

A failed deployment and a deployment made to address an incident are different events. One problematic release can lead to several follow-up deployments. An incident can also require a corrective deployment without having been caused by the immediately preceding release.

That distinction is why deployment rework rate and change failure rate can tell different stories about the same reporting period.

An illustrative release sequence

Suppose a service makes 30 deployments in a month. Four are unplanned responses to production incidents. Under that classification, the deployment rework rate is 4 divided by 30, approximately 13.3%.

The figure does not reveal how much engineering effort those four deployments consumed. One could be a straightforward configuration correction, while another requires days of investigation and implementation.

Make the classification auditable

Record why a deployment was considered incident-driven. A label added consistently by the release process is easier to examine than an inference based only on a commit message containing the word fix.

Do not classify all maintenance releases as rework. A planned reliability improvement can be deliberate investment even when it addresses a known weakness. Read the measure alongside the incident timeline and the team's planned work to understand whether urgent follow-up is repeatedly displacing other priorities.