Failed deployment recovery time

Name the failure and recovery boundaries

A meaningful duration needs two events. Teams must agree on when the failed deployment is recognized and what counts as restored service. A rollback being initiated is not necessarily the same as recovery being complete.

The reporting convention should remain consistent. A change to incident timestamps or closure practices can alter the result even when actual recovery behavior stays the same.

Walk through a recovery

Imagine an illustrative release that makes checkout requests fail. The team detects the regression, identifies the release, rolls it back, and confirms that the customer workflow works again.

The incident's administrative follow-up may continue afterward. A postmortem and a permanent fix can be valuable, but their completion should not automatically extend a measurement intended to describe service recovery.

Why the narrower scope helps

A broad MTTR report may mix deployment regressions with hardware problems, third-party outages, and operational mistakes. Those events have different recovery paths. Restricting the set to failed deployments supports a more focused delivery discussion.

Even within that scope, inspect the distribution and incident details. A single severe event can dominate a small sample. Pair the duration with the failure rate and customer impact, then examine whether deployment design, detection, or rollback capability constrained the response.