Code review time

Choose the interval first

Time to first response tells you how long an author waits before someone engages. Time to approval includes later discussion and revisions. Time to merge also includes branch checks, release rules, and administrative steps.

These intervals can move in opposite directions. A team might respond quickly but need several rounds to resolve a difficult design question. Another might approve quickly because reviewers are overloaded and comments are shallow.

An illustrative queue

Suppose a security reviewer is shared by three teams. First responses arrive within a day, but requests then wait two more days for final approval. A single review-time number hides the queue's location.

Break timing into stages and inspect representative changes. Look for ownership gaps, oversized requests, and policies that require specialist approval for routine changes.

Pair speed with evidence of quality

Review time does not establish whether a change is correct or maintainable. Read it alongside post-release defects, reverts, review findings, and developer feedback. Avoid targets that reward authors for opening tiny requests or reviewers for approving without reading.

The goal is a review process that gives useful feedback at the right time. A slightly longer review can be healthy when it prevents expensive rework. A long queue that adds no insight deserves a different response.