Skip to main content

Review latency

Time from PR open or first review request to first substantive review.

Review latency is how long a pull request waits before someone else engages with it. In the product you'll find it as Avg Member Review Time in the Team Activity table. It's typically one of the largest contributors to Lead Time for Changes.


​

What it measures


​

For each person, the average time between a pull request being opened and that person's first action on it — across the pull requests they did not author.


​

How Leanmote calculates it


​

avg_member_review_time = sum(first_action_at - pr_created_at) / reviewed_prs


​

  • It's an average, not a median, and the result is rounded to whole hours. A value of 0 means under half an hour, not instant.

  • The clock starts at the pull request's creation date. Leanmote does not track when a review was requested, so asking someone late doesn't shift the start.

  • The clock stops at the reviewer's first action of any kind on that pull request: their first comment, their first approval, or a commit they pushed to it. Pushing a commit to someone else's branch counts as reviewing it.

  • Pull requests you authored are skipped entirely, so this never measures anyone against their own work.

  • Actions recorded before the pull request's creation date are discarded rather than counted as negative.


​

Two things this metric does not do, despite being easy to assume:


​

  • It does not judge whether a review was substantive. An empty approval and a detailed critique stop the clock identically.

  • It does not adjust for working hours. A pull request opened on Friday evening accrues the whole weekend.


​

How to interpret it


​

Rules of thumb, not thresholds the product enforces. Remember the value is whole hours.


​

  • Under 4 hours is excellent — but on a raw-clock basis, so a team in one timezone will look better than a distributed one for the same behaviour.

  • 4–24 hours is typical for healthy teams.

  • Over 24 hours means cycle time is being burned on review pickup. Address with an SLA or rotation changes.


​

What to do about it


​

  • Set an explicit team review SLA (for example, "first review within 4 working hours").

  • Distribute reviews — auto-assign rather than letting authors hunt for reviewers.

  • Cap the review queue per person before people pick up new work.

  • Examine pull request size: large ones get delayed reviews. Smaller ones move this metric the fastest.


​

Related metrics


​

  • Lead Time for Changes

  • Time to First Approval

  • Review participation

  • Cycle Time

  • Waiting Time

Did this answer your question?