Renovate's own documentation says automerges take time. It can wait about two hours for a state where tests have passed and the branch is up to date with the base branch, and it automerges only one PR per target branch per run. Give it time, then check required checks, branch state and settings.
What the documentation says
The Renovate automerge guide is direct about timing. A PR cannot be automerged the second it passes the required tests. The maintainers advise waiting about two hours before troubleshooting, because Renovate needs to run at a point when tests have passed and the PR branch is current. If other people keep committing to the default branch, Renovate may find no gap to merge into.
It also explains why: after one branch merges, Renovate recalculates the Git state for the rest, since merging one can change or remove another's updates. Renovate requires automerging branches to be up to date with their target before it merges, and because merging several in a row is not reliable, it automerges one branch or PR per target branch per run.
Checklist when a green PR sits
- Is the PR really green on required checks? Optional checks do not count. Open the merge box and read the list.
- Is it up to date with the base branch? If main moved, the branch needs a refresh and a new CI run.
- Is another PR ahead in line? One merge per target branch per run means a queue of green PRs drains slowly.
- Is automerge enabled for this package rule? A packageRules entry may match patch updates but not minor ones. Check the rule's update type and dependency type matchers.
- Is the schedule open? A configured schedule can hold merges outside its window.
- Is platform automerge in play? Renovate uses the platform's native automerge by default. On GitHub that needs the repository's "Allow auto-merge" setting enabled.
- Is a merge queue involved? With a merge queue, workflows must also run on the merge group event, and the required checks must be set. The Renovate guide lists these steps.
What the maintainers recommend automerging
The guide suggests enabling automerge for updates where you would pick merge anyway, and keeping it off where you want to read the changelog or code first. It says automerge often works well for dev dependencies and can work for production dependencies when test coverage is good. It also gives an example that excludes versions starting with zero from automerge for minor and patch updates, because pre 1.0.0 versions can change in breaking ways under the SemVer specification.
Treat these as starting points, not rules. Your tests decide how much trust a green check deserves.
What not to do
Do not respond to slow automerge by loosening required checks. The delay is the price of a guarded merge. If the wait itself hurts, look at CI speed, at how busy the base branch is, and at grouping, so fewer PRs compete for each run.
For deeper reading on tool behaviour, see why do update bot pull requests keep getting rebased and do update bots work with merge queues and merge trains.
Try it yourself
Open the pull request gate demo and see how required checks decide whether a change can merge. A PR that is waiting is usually waiting on one of these.
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
Is two hours a hard rule?
It is the guidance in Renovate's documentation for when to start troubleshooting. Your schedule and queue may change the real wait.
Why does only one PR merge per run?
The documentation says merging more than one in a row does not work reliably, so Renovate merges one per target branch per run.
Sources
Last reviewed: 19 October 2026.
