What Does “Stale” Mean for a Pull Request?
An old pull request may be waiting on feedback, blocked, superseded or forgotten. How to check what happened and decide whether to resume or close it.
I had a pull request I was working on, then I was moved to something else. After that, my priorities changed again. And again. Eventually I forgot about the PR.
I've also been on the reviewer side of this. I left a comment on a colleague's PR, the author moved to another area, and it stayed there for months.
In both cases, the people working on the change had moved on. I wouldn't know from the age of the PR whether the work was still wanted. I'd have to ask.
A stale pull request usually means one that has gone without activity long enough to attract attention. The threshold depends on the team's policy or tooling.
Read the last exchange before sending a reminder
Read the recent discussion and the unresolved review threads. If a reviewer asked for a change and the author hasn't answered, ask whether the author can still pick it up. If the author already replied with an explanation, read that reply before asking them for an update. The next action may belong to the reviewer.
This is easy to get wrong when all you have in front of you is a list sorted by age. My comment on my colleague's PR was still there, but they'd moved to other work. Another copy of the same request would have left that part unchanged.
I'd ask whether the change is still planned and who can take it forward now. That conversation might bring the original author back, or it might reveal that someone else needs to take over. The answer matters before anyone spends an afternoon fixing up the branch.
For a PR that has already been approved, check what remains before merge. There might be a dependency or an unfinished check. Check whether the approval still applies to the code you would merge.
The earlier guide to who owns the next move covers ordinary handoffs. With old work, there is an extra question: does the person named in that handoff still have time allocated to it?
Several different situations get called stale
For a backlog review, I'd use the following distinctions.
| What you find | What to do next |
|---|---|
| No recent activity, and no clear explanation | Ask whether the work is still wanted and who can resume it. Leave the outcome on the PR. |
| Feedback waiting on the author | Confirm the author still owns the work. If priorities changed, agree on reassignment or an explicit pause. |
| An author response waiting on a reviewer | Read the response, then arrange the next review or find someone who can do it. |
| Approved, but not merged | Check the remaining merge conditions and confirm who will perform the merge once they are met. |
| A known dependency or blocker | Name what has to change before work can resume. Link the dependency and identify who will notice when it clears. |
| Another change has replaced the work | Check that it covers the original need, then close the old PR with a link to the replacement. |
| The work is no longer planned | Confirm that decision with whoever owns the priority, then close the PR with the reason. |
The first row is where I'd put my forgotten PR until that conversation happens. Repeated reprioritization explains how it disappeared from my day. It doesn't tell me whether the original need disappeared too.
There is also a perfectly reasonable answer of “still wanted, nobody available right now.” Write that down. Give the pause a point at which someone will reconsider it, perhaps after the work that displaced it finishes. If nobody can name a return point, consider closing the PR and keeping the unfinished need in the backlog, with a link to the review. Make that an explicit decision with the person responsible for the work. Leaving it open is also a choice, but someone should agree to revisit it.
A stale bot can apply a policy
The actions/stale action can mark and close pull requests after configured periods of inactivity. It also supports exemptions and configurable behavior when activity resumes. The thresholds and exemptions belong to the policy configured for that repository.
That can be useful for applying an agreed cleanup policy. But the action's inactivity threshold can't answer the question I have about my own forgotten work: would someone still want this finished if they remembered it existed?
Before using automatic closure, decide which PRs the policy should cover and what the message asks people to do. Work paused on a known dependency needs different handling from a contribution whose author has stopped responding. For a nonresponding contributor, an agreed response window can end with closure and a note explaining how to bring the work back for consideration. That is a maintenance decision made with incomplete information.
Automatic reminders can add noise when nobody has capacity or the change is no longer wanted. For the cases I described, I would want a decision about the work before another reminder to continue it.
When you decide to resume it
Confirm the original problem still exists before updating the branch. Check whether another change addressed it while this one was waiting. If someone new is taking over, give them the reason for the original approach and the unresolved review discussion, including any disagreement.
Then inspect how the surrounding code has changed. A comment left months ago may still identify a real issue, but its suggested fix may no longer fit. The re-review guide explains when to widen the check beyond the latest edits. Coming back after months is a good reason to reconsider how much of the earlier review you can rely on.
PR Flow's pull request dashboard shows why a change needs you or who it is waiting on. Use that as a starting point for reading the handoff: the person the review is waiting on may have moved to other work. The priority conversation still has to happen outside that status.
I don't have a number of inactive days at which I'd automatically close my forgotten PR. I'd first want to know whether anyone still needs it. If they do, the difficult part is deciding which current task makes room for it.