TL;DR
The cost: A pull request sitting unreviewed for days doesn't just delay that one change — it delays everything stacked behind it, and the longer it sits, the more expensive the eventual review gets as context fades and the branch drifts from main.
What doesn't work: Just telling people to "review faster." Review time is usually a visibility and process problem, not a discipline problem.
What works: Making stale PRs visible before they're old, reducing PR size, clarifying who's actually on the hook to review, and, increasingly, having something other than a human notice when a PR has gone quiet.
Why PR Review Time Matters More Than It Looks Like It Should
A PR that sits for four days doesn't cost four days of nothing — it costs four days of the branch drifting further from main, the author's context fading, and anything depending on that change staying blocked. Multiply that across a team running several PRs at once and review latency becomes one of the largest, least visible sources of delay in the entire delivery pipeline. It rarely shows up as a line item anywhere, which is exactly why it's so persistent.
The Usual Culprits
No clear owner. A PR gets opened, tagged to a team rather than a person, and everyone assumes someone else will pick it up. Diffusion of responsibility is the single most common reason a PR goes stale.
Reviews that require too much context to start. A 900-line PR touching six files is a much bigger ask than a 90-line PR touching one — reviewers put off the big ones because starting requires blocking out real time, and that time rarely appears on its own.
No visibility into what's actually waiting. Without something actively surfacing that a PR has been open for days with no review, it's invisible until someone happens to check the repo, which for a busy engineer can be a while.
Async time zones without a handoff process. A PR opened at the end of someone's day in one time zone can sit for eight-plus hours before a reviewer in another zone even sees it, and without a deliberate handoff it often sits even longer.
What Actually Reduces Review Time
Keep PRs small on purpose. This is the highest-leverage change and the hardest to enforce culturally. A PR under roughly 200 to 300 lines gets reviewed meaningfully faster than a larger one, because the cognitive cost of starting the review is so much lower. Splitting work into smaller, sequential PRs, even if it means more of them, usually nets out faster overall.
Assign a specific reviewer, not a team. "Someone on backend should look at this" reliably takes longer than naming an individual. If your review tooling supports auto-assignment based on code ownership, use it rather than leaving it to whoever notices first.
Set, and actually enforce, an SLA. A soft rule like "PRs get a first pass within one business day" only works if something surfaces the ones that miss it. Without enforcement, an SLA is just a sentence in a wiki nobody rereads.
Make staleness visible before it's old. The difference between a two-hour delay and a four-day delay is almost always visibility, not effort. A PR that's flagged the moment it crosses a threshold, whether that's six hours or a day, gets picked up far faster than one that only becomes visible when someone happens to scroll the repo.
Have something other than a human track it. This is where most of the manual effort above tends to quietly fail, since humans forget to check and "someone should build a dashboard for this" rarely gets built. Scrummer's GitHub integration surfaces stale PRs and review-time signals directly in the same Slack channel where the team already coordinates blockers and standups, so a PR that's gone quiet gets flagged the same way a blocked ticket would, rather than requiring someone to remember to look.
What Doesn't Actually Help
Telling the team to "prioritize reviews" without changing anything structural rarely sticks past the first week, since it's asking people to remember something under the same conditions that caused the problem in the first place. Adding more required reviewers per PR also tends to backfire: it multiplies the diffusion-of-responsibility problem above rather than fixing it, since now several people can each assume someone else will go first.
Frequently Asked Questions
What's a reasonable target for PR review time?
There's no universal number, but many teams aim for a first response, not necessarily an approval, within one business day, with same-day review common for smaller, urgent changes. The more useful benchmark is your own trend over time, whether review time is going up or down, rather than an external target.
Does PR size actually matter that much?
Yes. Reviewers consistently take disproportionately longer per line on large PRs, both because the cognitive load is higher and because large PRs get put off in favor of smaller, faster tasks. Splitting work into smaller sequential PRs is one of the few changes with reliably strong evidence behind it.
How do you stop PRs from sitting over weekends or across time zones?
Explicit handoff conventions help, flagging a PR as needing review before someone's day ends rather than assuming the next person will notice it on their own. Automated alerts that don't depend on someone manually checking are more reliable than relying on time zone awareness alone.
Can automation actually shorten review time, or does it just report on it?
Both, depending on the tool. Analytics platforms report on review time after the fact, which helps you see trends but doesn't change any individual PR's outcome. Tools that surface a specific stale PR in the channel where the team already works, as a blocker, in real time, actually shorten the delay for that PR, not just the next quarter's dashboard.
See Stale PRs Before They Cost You a Sprint
See how Scrummer surfaces PR and review-time risk alongside your standups and blockers, or try it free.