How to Reduce Stale PRs and Unassigned Work

The Hidden Cost of Stale Pull Requests

Every engineering team has them: pull requests that were opened days or weeks ago and have quietly drifted out of sight. Maybe the author got pulled onto something urgent. Maybe the reviewer never got around to it. Whatever the reason, stale PRs represent real cost — and most teams underestimate just how much.

When a PR sits idle, the code it touches keeps changing underneath it. Merge conflicts accumulate. The author loses context on their own changes and has to re-familiarize themselves before addressing review comments. Other developers working in the same area risk duplicating effort or building on top of code that will change. The result is wasted cycles, frustrated engineers, and slower delivery.

What Makes a PR "Stale"?

There is no universal definition, but a practical threshold is seven days without a meaningful update — no new commits, no review comments, no status change. At that point the PR is almost certainly blocked or forgotten, and the longer it lingers, the more expensive it becomes to resolve.

Some teams use stricter thresholds: 48 hours for critical-path work, five days for everything else. The specific number matters less than having one at all. Without a clear definition, stale PRs blend into the background and nobody owns the problem.

Proactive Notifications

The first step to fixing stale PRs is making them impossible to ignore. Octoboard has an in-app notification centre, laid out like an inbox, that raises a notification when a pull request crosses your staleness threshold. Each item can be left unread, marked read, or dismissed, so the ones you have already dealt with stop competing for attention. Nothing leaves the app and there is no inbox to unsubscribe from.

The same notification system flags unassigned issues. An issue without an owner is an issue that will not get done. By surfacing unassigned work early, teams can triage and distribute load before it becomes a bottleneck at the end of the sprint.

Automatic Risk Detection

Beyond notifications, Octoboard applies two staleness thresholds to every open pull request and issue. A pull request with no activity for longer than the PR threshold is flagged as stale; the default is 7 days. An issue with no activity for longer than the issue threshold is flagged the same way; the default is 14 days. Both are set per workspace in Settings, so you can tune them to match your team's norms. Alongside those, work with no assignee is surfaced on its own, because an issue without an owner is an issue that will not get done.

There is also an activity horizon, 180 days by default, which keeps long-abandoned work out of the picture entirely. Anything older than the horizon is excluded from workload, the leaderboard, My Work, Risks, and Blocked, so a repo full of issues nobody has touched since last year does not drown out the work that is actually moving. Set it to zero to turn it off.

The goal is not to enforce rigid rules — it is to surface the things that are likely to cause problems so someone can make a conscious decision about them.

Team Accountability and Per-Developer Metrics

Visibility alone is not enough. Teams also need accountability, and that starts with knowing who is doing what. Octoboard's leaderboard ranks contributors on two numbers: issues closed and pull requests merged in the selected period. Each person also gets an open-work count and an eight-week trend sparkline, so you can see whether their throughput is rising or falling. Review turnaround is measured too, but at the organization level as p50, p75, and p90 percentiles rather than per person. The point is not to create competition, it is to make workload imbalances visible.

When one developer is carrying most of the merges for the team, that should be obvious. When another has three pull requests sitting past the stale threshold, the team lead should know before the standup, not during it. These metrics turn anecdotal impressions into data and make it easier to have productive conversations about workload distribution.

Putting It All Together

Reducing stale PRs is not about adding more process. It is about making the right information visible at the right time. Set your staleness thresholds, watch the notification centre, and use the leaderboard to keep the team balanced. The result is faster reviews, fewer merge conflicts, and engineers who spend their time writing code — not chasing down forgotten pull requests.