Automerge is slow by design. One bot's documentation says it waits for required checks and an up-to-date branch, merges only one pull request per target branch per run, then recalculates everything. Allow about two hours. A merge queue or a smaller set of auto-mergeable updates speeds it up.
What happens after tests pass
You might expect a passing pull request to merge the second its checks go green. In the documentation of the bot we read, that does not happen. It needs a run in which your tests have passed and the branch is current with the base branch. If other people keep committing to the default branch, the tool may never find a gap to merge into.
After one merge, the tool must work out the state of every other branch again, because merging can change or even remove another branch's updates. Since merging several branches in a row is described as unreliable, it merges one branch per target branch per run.
Why lockfiles make it worse
When the repository has a lockfile, one merged update tends to conflict with the next. The documentation walks through the case: two updates are created, the first passes and merges, the second now conflicts, the tool rebases it, tests rerun, and it merges after passing. That sequence can take several runs. It is still better than waking up to two pull requests and resolving the conflict yourself.
Ways to speed it up
- Use the platform's native automerge or merge queue. The documentation says the bot supports queues on one code host and merge trains on another, and that when a queue exists, it rebases only on conflict because the queue already tests against the head of the base branch.
- Enable automerge only for updates you would merge without reading anyway. The maintainers recommend this: keep it off where you want to read changelogs or code first.
- Limit it to development dependencies, patch releases and similar low risk classes first. The documentation says automerge often works well for development dependencies.
- Group low risk updates so one pull request replaces many.
- Avoid committing to the default branch during the update window where you can.
Silent merges and the notification trade
Even with automerge you still get a notification when a pull request opens and again when it merges. The documentation offers a branch mode that pushes passing updates straight to the base branch and opens a pull request only if tests fail. That is quiet, but it needs branch protection to allow the push, and it removes the pull request as a review record. For regulated teams, a pull request trail is often worth the noise.
When automerge looks stuck
Check the pull request body first. The documentation says it should show that automerge is enabled, and a message that it is disabled by configuration means your rule did not match. Also check for the absence of required checks. By default the bot merges only if every status check succeeded, and there is an option to merge without any tests, which the documentation warns can break the base branch. Do not use it as a shortcut.
Quick check
Is slow automerge a sign something is broken?
Often not. One merge per run and a recalculation after each is intended behavior in the documentation we read.
Is it safe to automerge with no tests?
The documentation warns against it, because broken builds can reach your base branch. Add at least a build and a basic test first.
Safeguard adds policy gates on pull requests, so a change can be blocked when a dependency policy fails. It also builds an SBOM from manifests and lockfiles and uses reachability analysis to show which flagged packages your code calls. Fix pull requests are off by default, with every category on Manual. A free scan is available.
Sources
Last reviewed: 19 October 2026.
