An old fix PR is a decision you postponed. GitHub says Dependabot stops rebasing a pull request that has not been merged for 30 days. After that you can still rebase and merge it by hand, but first ask whether the fix is still needed, still safe, and still the right version.
What happens at 30 days
GitHub's documentation states that Dependabot automatically rebases pull requests to resolve conflicts by default. If a pull request has not been merged for 30 days, Dependabot stops rebasing it. You can still rebase and merge manually. You can also turn off automatic rebasing entirely with the rebase-strategy option, though PRs opened before you disable it keep being rebased until 30 days after they were opened.
Other tools behave differently, and you should read your own tool's documentation. The point is that a bot PR does not stay fresh forever, and a stale branch is a sign that nobody owns it.
Four questions to ask about the old PR
- Is the vulnerability still present in what you ship? Re-run your scan on the main branch. If a later change already moved the package, the PR is dead weight.
- Is there a newer fixed version? An advisory sometimes gains a better patched release, or a newer release fixes a regression in the older one. Check the current advisory, not the PR text.
- Is the package still used? A dependency removed since the PR was opened makes the PR moot.
- Why did nobody merge it? A failing test, an unclear owner, or a fear of breakage each need a different next step.
Decision table
| Finding | Action |
|---|---|
| Fix still needed, tests green after rebase | Rebase, review, merge |
| Fix still needed, tests red | Fix the test or the code in a separate branch, then merge |
| Newer fixed version exists | Close the old PR, let the bot open a fresh one, or bump by hand |
| Package gone or already updated | Close with a one line reason |
| Unsure and the risk is real | Assign an owner today, with a date |
Record why you closed it
Closing silently is how the same PR returns next week. Write a reason in the PR before you close it: "package removed in a later change" or "superseded by version X". If you are closing because the risk is accepted, that is a risk decision, not housekeeping. Put it in your exception record with an owner and a review date. The same pattern applies to tickets: see stale security tickets: close, fix or accept rules.
Prevent the next one
Old PRs usually mean one of three problems. There is no owner, so route bot PRs to code owners (see codeowners for bot opened pull requests). The open PR limit is full of low value updates, so group them. Or the test suite is too slow or too flaky to trust, which no bot setting fixes.
A small weekly habit helps: list bot PRs older than two weeks and decide each one in a few minutes. The goal is not an empty queue. The goal is that every open PR has an owner and a reason to stay open.
Try it yourself
Open the demo and see how an exploitability check changes the urgency of a finding. Use that view to decide whether an old fix PR still matters.
Click through it at your own pace, or open it full screen.
Safeguard can open fix pull requests through autonomous remediation. It is off by default and every category starts on Manual, so a person approves each change. You can also run a free scan to see which dependencies have known fixes before you decide what to automate.
Quick check
Does Dependabot close old pull requests by itself?
The documentation we checked describes rebasing behaviour, not automatic closing. Check your own repository settings and your tool's documentation before you rely on either.
Can I still merge a PR after Dependabot stops rebasing?
Yes. GitHub says you can still manually rebase and merge it. Re-run your tests after the rebase.
Sources
- GitHub Docs: Managing pull requests for dependency updates
- GitHub Docs: Dependabot options reference
Last reviewed: 19 October 2026.
