Deployment rework: identify unplanned repair releases without hiding planned work

Last updated: 5 Oct 20266 min read

tutorial

Deployment rework measures the share of production deployments made as unplanned work in response to a production incident. It differs from change fail rate: a failed deployment belongs to the failure numerator, while one incident may drive several subsequent repair deployments. Record the intent when a deployment is requested, link it to the incident, and preserve later corrections as auditable changes. If one deployment mixes a planned feature and an urgent fix, define an explicit classification rule and report the mixed case separately where volume matters. A silent relabel after the fact makes the trend impossible to trust.

Operational decision

In the same 26-activation month, four activations are urgent repairs tied to production incidents. The observed rework share is 4 divided by 26, or about 15.4 percent. One incident caused two repair deployments because the first patch only fixed the API and the second corrected cached HTML. Both deployments consume delivery effort; the incident itself is counted once in the incident ledger. A planned security patch that follows the normal review and schedule is not automatically rework merely because it changes a vulnerability. For every release, keep request time, planned or repair intent, incident link if any, approving owner, and the public outcome.

Production activations: 26
Unplanned incident-repair activations: 4
Rework share: 4 / 26 = 15.4% after rounding
Incident with two repairs: two deployment events, one incident
Mixed feature and repair: separately flagged by policy
Audit: preserve original intent and later correction

Cost and verification

Classification is O(D) review work for D deployments unless it is captured in the release workflow. Automated incident links reduce clerical cost but still need human review for mixed intent. A falling rework share can mean fewer incidents, more planned deployments in the denominator, or missed tagging; inspect the absolute repair count and customer impact alongside the ratio. Do not reward teams for suppressing incident links. Use the measure to find recurring repair paths and remove their causes.

Common Mistakes

Do not treat every unplanned deployment as an incident repair without an incident link.
Do not count one incident as only one repair deployment when it required several.
Do not hide mixed intent by changing labels after the report closes.

Connected lessons

Practice and check

devops

delivery-measurement