PRs that sit in review aren't just slow — they're actively costing your team.
Every day a PR sits, the cost of merging it increases. Here's why stale PRs
compound into bigger problems, and how to catch them early.
The hidden cost of a stale PR
You open a PR on Monday. By Wednesday, it hasn't been reviewed. By Friday,
there are merge conflicts. By the following Monday, you have 3 hours of
rebasing to do before you can even get feedback.
Here's the math on why this is expensive:
Day 1: Author context is fresh. Review is easy.
Day 2: Author starts working on something else. Context decays.
Day 3: Merge conflicts appear. Rebase needed.
Day 4+: Author has moved on completely. Review takes 2x longer.
A PR that should take 30 minutes to review on Monday takes 90 minutes on
Thursday because both the author and reviewer have lost context.
DORA Metrics Calculator
Catch stale PRs before they cost you
Deviera flags PRs that stall in review and nudges reviewers automatically — no more 3-day silent rot.
Most stale PRs aren't caused by lazy reviewers. They're caused by structural problems:
No explicit reviewer assigned: "Anyone can review" means no one does
Reviewer overload: Too many PRs, not enough reviewers
Large PRs: Big PRs are harder to review, so they sit longer
Complex code: PRs in unfamiliar areas take longer to review
No SLA: "We'll get to it" means "we'll get to it never"
How to measure PR stagnation
Track these metrics:
PRs open > 48h: Count of PRs that haven't received first review in 48h
PRs open > 72h: Count of PRs open for 3+ days
Average time to first review: Time from PR open to first comment
Abandoned PR rate: PRs closed without merge, as percentage of total
If more than 20% of your PRs are stale (open > 48h), you have a bottleneck.
The escalation pattern
The earlier you catch a stale PR, the cheaper it is to fix. Here's the escalation:
0–24h
Healthy — normal review window
24–48h
At risk — ping the reviewer
48–72h
Stale — context decaying, rebases pile up
72h+
Critical — merge conflicts + lost context
The cost of a stale PR compounds with age. Caught at 24 hours it's a 15-minute fix; left to 72+ hours it's a multi-hour rebase against a decayed mental model — for both author and reviewer.
0-24h: PR is healthy. Normal review expected.
24-48h: PR is at risk. Ping in Slack: "Hey, can someone review this?"
48-72h: PR is stale. Escalate: assign specific reviewer, prioritize.
72h+: PR is critical. Bring up in team sync. What's blocking?
Why the reviewer isn't the problem
The instinctive response to a stale PR is to chase the reviewer. It rarely works,
because the reviewer is usually the symptom rather than the cause. Three structural
factors produce far more stale PRs than individual slowness:
PR size. A 40-line diff gets reviewed in a gap between meetings. An 800-line diff needs a scheduled block of focus, and that block keeps getting deferred. Size is the strongest predictor of how long a PR waits, and it is entirely within the author's control.
Review load concentration. If two people are the de facto reviewers for everything, staleness tracks their calendars rather than the team's capacity. Measure open PRs per reviewer; once one person carries more than three or four, latency climbs sharply.
Ambiguous ownership. A PR that names no reviewer belongs to nobody. Everyone assumes a colleague with more context will take it, and the PR waits for a volunteer who never arrives.
This matters because the remedies are different. Chasing reviewers harder produces
resentment and a brief improvement that decays within a fortnight. Shrinking PRs,
spreading review load, and assigning explicitly change the conditions that made the
PR sit in the first place — and they keep working when nobody is watching the
dashboard.
Prevention strategies
Don't wait for PRs to go stale. Prevent it:
Assign reviewers at open: Don't leave PRs unassigned
Set explicit SLAs: "First review within 4 hours" is a commitment
Rotate review duty: Make review a shared responsibility
Auto-remind after 24h: Send automated reminder if no review
What to do this week
Audit your open PRs: How many are over 48h old?
Assign explicitly: Every open PR should have a specific reviewer
Set a team SLA: Agree on "first review within X hours"
Monitor weekly: Track stale PR count each week, set a target
A stale PR is a warning sign, not a catastrophe. Catch it at 24h, not 72h.
That's the difference between a 15-minute fix and a 3-hour rebase. Deviera's
Signal Feed
detects stale PRs automatically and posts a Slack alert tagging the assigned
reviewers — no manual monitoring needed. See full
PR review time benchmarks
to know what "healthy" looks like at your team size.
Frequently asked questions
When is a pull request considered stale?
The practical threshold for most teams is 24 hours without review activity, not the 7 or 14 days platform defaults suggest. The reason is cost, not tidiness: at 24 hours the author still holds the context and a rebase is usually trivial. By 72 hours the branch has diverged, the author has moved to other work, and picking the review back up means reconstructing why the change was made. Set the threshold at the point where recovery is still cheap rather than the point where the PR looks abandoned.
Why do pull requests go stale even on small teams?
Almost always because no specific person was asked. A PR opened to a team rather than a named reviewer waits for a volunteer, and everyone reasonably assumes someone else with more context will pick it up. Small teams are not immune — they are simply slower to notice, because there is no queue depth making the delay visible. Explicit reviewer assignment at PR creation removes the ambiguity and is the single highest-leverage change most teams can make.
Should stale pull requests be closed automatically?
Rarely, and it often makes things worse. Auto-closing discards completed work and signals that the review process failed rather than fixing it, and authors quickly learn to reopen closed PRs, which adds noise without changing throughput. Escalation works better than closure: notify the assigned reviewer at your threshold, escalate to a second reviewer if it keeps waiting, and reserve closing for PRs the author has genuinely abandoned.
What is a healthy number of stale PRs?
Track it as a percentage of open PRs rather than an absolute count, because the raw number scales with team size and tells you little on its own. A healthy team keeps stale PRs under roughly 10% of everything open at any moment. What matters more is the direction: a stale count climbing week over week means review capacity is not keeping up with the rate PRs are opened, which is a staffing or assignment problem rather than an individual one.
