Review latency measures how long pull requests wait between being opened (or having a review requested) and receiving their first substantive review. It's typically the largest contributor to Lead Time for Changes.
What it measures
Median elapsed time from pr.opened_at (or review_requested_at) to first_substantive_review_at.
How Leanmote calculates it
review_latency = median(first_review_at - opened_or_requested_at)
Median is the default to avoid outlier distortion. P75 and P90 are also exposed for slow-tail visibility.
Substantive review excludes empty approvals or comments that don't engage with the change, when detectable.
Working hours can be respected so weekend gaps don't inflate the metric (configurable).
How to interpret it
Under 4 hours (median) on a working-hours basis is excellent.
4–24 hours is typical for healthy teams.
Over 24 hours means cycle time is being burned on review pickup. Address with SLA or rotation changes.
What to do about it
Set an explicit team review SLA (e.g., "first review within 4 working hours").
Distribute reviews — auto-assign rather than letting authors hunt for reviewers.
Block writing new code if review queue exceeds N items per person.
Examine PR size: huge PRs get delayed reviews. Smaller PRs lift this metric the fastest.
Related metrics
Lead Time for Changes
Review participation
Cycle Time
Waiting Time