The stale PR problem: why code review bottlenecks compound silently

A pull request is stale the moment it stops moving. No review requested. No comments. No approval. Just sitting in the queue, accumulating merge conflicts and context decay while the author moves on to something else.

The cost compounds, not adds

The naive calculation: a 3-day review delay costs 3 days of shipping velocity. The real cost is higher, because delay isn't linear — it compounds.

• Merge conflicts accumulate as other PRs land. What was a clean diff on Day 1 requires 2 hours of conflict resolution on Day 4.
• Context decays. The author who wrote the code clearly on Monday can barely remember why they made certain choices by Friday.
• Reviewer friction. A large, drifted PR is harder to review than a fresh, focused one — so reviewers procrastinate further.
• WIP pressure. While the PR sits, the author is mentally maintaining two things: the stale PR and whatever they've moved on to.

Why teams don't catch it earlier

Most teams rely on the author to chase reviewers, or on the reviewer to happen to notice the PR in their queue. Both are manual, unreliable processes. GitHub doesn't send a notification when a PR has been open for 48 hours with no activity. Linear doesn't know about your PRs at all.

The signal that a PR is stale exists — it's just not surfaced anywhere. Deviera's stale PR scanner runs every 6 hours and checks every open PR across all monitored repositories for the configured inactivity threshold.

What the data shows

Based on typical patterns in software teams, PRs that go unreviewed for more than 48 hours have a significantly higher probability of requiring conflict resolution before merge. The first 24 hours after a PR is opened is the highest-value review window — coverage, fresh context, and minimal drift.

A practical threshold: 48 hours

The default stale threshold in Deviera is 48 hours. This is conservative enough to avoid noise on PRs that are intentionally parked (draft PRs, weekend work) but aggressive enough to catch real bottlenecks before they compound.

Teams with faster review cultures can set the threshold lower (24 hours). Teams with global distribution and timezone gaps might set it to 72 hours. The threshold is configurable per automation rule.

The fix: proactive, structured notification

When a PR is flagged as stale, Deviera does two things by default:

1. Creates a Linear issue with the PR link, author, and assigned reviewers — so it's tracked, not just noticed.
2. Posts a comment directly on the PR — visible to the author and reviewers — with a link to the Linear issue.

This doesn't eliminate the need for human review. But it makes the invisible visible — and that's usually enough to get a response within the same day.