Escaped review defect

What the measure captures

An escaped review defect is a problem that passes through review and is discovered later in testing, production, or user feedback. It is most useful when the team states the unit of analysis, the start event, the completion event, and the population being measured. A review request, a pull request, and a merge are related events, but they are not interchangeable. Keeping those boundaries visible prevents a dashboard from turning an operational signal into an unexplained score.

A practical example

A regression found after release can be traced back to the reviewed change, then examined for missing tests, unclear ownership, or a hard-to-see interaction. Start with a small sample and inspect the underlying requests before creating a target. Record the repository, change type, reviewer path, and relevant policy state. That makes it possible to explain an unusual result instead of simply celebrating or escalating a number. Compare similar work over time and annotate major changes in ownership, branch rules, or automation.

How to use it carefully

Attribution is uncertain. Not every later defect was reasonably detectable in review, so avoid using escapes as automatic blame. Review metrics work best as prompts for team-level investigation. Combine them with review samples, author and reviewer feedback, escaped defects, rework, and delivery outcomes. Avoid ranking individuals from a single measure because review difficulty, system familiarity, and assignment patterns vary. A healthy process makes useful feedback available at an appropriate time while preserving accountability for the final change.

How this relates to Weave

Weave can connect review events with change context and delivery signals so teams can inspect escaped review defect alongside review time, pull request size, and flow. That context helps teams investigate queues and quality patterns without treating one review number as a verdict on an engineer.