Deploy free

Time to first review: the number that quietly runs your lead time

Review Pickup Time tracks time to first review — the average hours a PR sits open before anyone looks at it, plotted weekly against Elite (under 4h), High (under 24h), and Medium (under 72h) bands. It's pulled from GitHub, GitLab, and Azure DevOps. Most "slow shipping" complaints trace back to this one number, not to how fast people write code.

deckgauge · Board · Intelligence
Time to first review (weekly avg)Elite/High zone (under 24h)

Weekly time to first review, mostly inside the healthy band.

What it measures, and where the data comes from

One number per week: the average hours between a PR opening and its first human review. Not the full review cycle, not time-to-merge — just how long the PR sat waiting for someone to start looking. That isolates review latency from coding time, rework, and CI delay, which is why it's a sharper diagnostic than lead time alone.

  • GitHub — from pull request open to the first submitted review (approval, request-changes, or comment) by a human reviewer.
  • GitLab — from merge request open to the first reviewer approval or review note.
  • Azure DevOps — from pull request creation to the first reviewer vote.

Bot reviews, CI status checks, and the author's own comments don't count as a first review — only another person weighing in does.

How to read it

Look at the band the line sits in before you look at the exact hour count. Elite (under 4h) means review is basically part of the same working session as opening the PR — nobody's waiting. High (under 24h) is healthy: a PR opened in the afternoon gets looked at by the next morning. Medium (under 72h) is a team that treats review as a side quest. Below that, PRs are aging out of people's short-term memory before anyone reads them.

Watch the trend more than any single week. A line that ticks up two or three weeks running is a reviewer-capacity problem forming in real time — it's much cheaper to fix at High-drifting-to-Medium than after it's been Low for a quarter.

What it tells you over time

A flat line in the Elite or High band means review isn't your bottleneck — if delivery still feels slow, look elsewhere (PR size, CI, or approval-count policy). A line climbing band by band, week over week, is almost always reviewer bandwidth: either too few people can approve PRs in a given area, or the people who can are buried in their own work. A jagged, repeating pattern instead of a smooth trend usually means coverage, not capacity — a specific day or window keeps going unreviewed.

Example situations

1. Pickup time climbing while merge volume holds steady

deckgauge · Review Pickup Time
Time to first review — 8h → 62h over 8 weeksMerge volume: ~32/wk, flat

Rising pickup time, output unchanged.

What you're seeing: pickup time has climbed from Elite straight through High and Medium into Low, but the team is still merging the same number of PRs per week. Nobody's blocked yet — they're just waiting longer and longer before anyone looks.

How to react: this is reviewer overload or too thin a reviewer roster, not a motivation problem. Check who's actually approving PRs — if it's the same two or three names carrying the whole team, that's your answer. Flat merge volume with rising pickup time means people are quietly absorbing the wait, which doesn't show up anywhere else until it becomes attrition or a missed date.

Managerial playSet a pickup-time SLA the team owns collectively — first review within 4 working hours — rather than leaning on one person to "be faster." Grow the reviewer roster: get more people approved to review the areas that are bottlenecked, even if that means pairing a mid-level engineer up for a few sprints. And make review load visible in the same breath as shipping — the person who unblocks five PRs a day is doing real, high-leverage work, and your recognition system should say so.

2. Recurring weekly bumps lined up with a thin coverage window

deckgauge · Review Pickup Time
Time to first review, spiking every other weekSpikes fall on the same on-call window

Sawtooth pattern, same weeks every time.

What you're seeing: the line isn't drifting, it's sawtoothing — sharp spikes on a regular cadence, then back to normal. That pattern points at a schedule gap, not a trend: whoever's supposed to review during a specific window (an on-call rotation, a timezone-thin stretch, a specific reviewer's day off) isn't around, and PRs opened in that window just wait.

How to react: don't add process for this — fix the calendar. Cross-reference the spike weeks against your on-call and PTO schedule; it'll usually line up exactly. If your team spans timezones, check whether review capability clusters in one region and goes dark for the other's morning.

Managerial playPut review duty on an explicit rotation with a named owner per window, the same way you'd staff on-call. If the team spans timezones, spread reviewer permissions across regions so there's always someone awake who can approve — don't let review coverage be a side effect of where headcount happened to land.

Frequently asked

What is review pickup time?
The average hours a pull request sits open before anyone reviews it, plotted weekly against Elite (under 4 hours), High (under 24 hours) and Medium (under 72 hours) bands, across GitHub, GitLab and Azure DevOps.
Why does time to first review matter so much?
Because most complaints about slow shipping trace back to this number rather than to how fast people write code. Waiting time, not working time, is usually the larger share of lead time.
What should I do when review pickup time slips?
Look at reviewer participation and pull request size before adding process. Pickup time usually slips because review load is concentrated on a few people, or because the pull requests are too large to review in a spare half hour.

Related widgets

Last updated