Rework Rate

/
Glossary
/
Rework Rate

Rework rate is the percentage of work that has to be redone because of incorrect understanding, faulty diagnosis, or actions taken on a flawed hypothesis, formally introduced as a stability metric in the 2024 DORA State of DevOps Report.

The 2024 DORA Report introduced rework rate as a formal stability measure precisely because the cost of acting on wrong understanding had become large enough to require its own metric. In the context of incident response, rework manifests as wrong rollbacks, paging the wrong team, deploying fixes that don't address the actual cause, or pursuing a hypothesis for 30+ minutes only to discover it was coincidental. None of these costs show up in MTTR or availability metrics directly: but they extend incidents, burn senior engineer attention, and erode confidence in the response process.

Rework is not random. It's systematically biased toward visible, recent, and familiar causes. The deployment that happened an hour before the incident becomes a compelling hypothesis regardless of whether it was actually causal. The service that always seems to be involved when things go wrong becomes a default suspect. The first alert that fires shapes the mental model of the first responder, who shapes the mental model of the room. The initial hypothesis, once voiced, accumulates social momentum faster than evidence can be gathered to evaluate it. Experienced incident commanders develop a deliberate practice of hypothesis skepticism, but the discipline is rare and competes against organizational pressure to act.

AI SRE reduces rework rate by producing causally-grounded hypotheses with evidence chains, rather than letting the bridge anchor on the first plausible verbal theory. When the responder opens their laptop and finds a ranked hypothesis set with supporting evidence already assembled, the probability of pursuing the wrong explanation drops materially. Rework rate is an underused metric for evaluating reliability program effectiveness. It captures something MTTR can't, and it's directly responsive to the improvements an AI SRE delivers.

Related

MTTR (Mean Time to Resolution)

MTTR (Mean Time to Resolution) is the average time it takes to fully resolve a production incident — from initial detection through investigation, remediation, and verification that the issue has been corrected. It is the headline metric for incident response programs.

Incident Response

Incident response is the structured process of detecting, diagnosing, and resolving production issues that affect users, encompassing alert triage, investigation, remediation, and post-incident learning.

Root Cause Analysis (RCA)

Root cause analysis (RCA) is the practice of identifying the underlying cause of a production issue, not just the surface symptom or the proximate trigger, but the deeper conditions that allowed the failure to occur and would allow it to recur if not addressed.

Postmortem

A postmortem is a structured retrospective conducted after a production incident to document what happened, identify root causes, and capture action items that prevent the same failure from recurring, typically blameless in tone and oriented toward systemic rather than individual fixes.