Developers ignore bot pull requests when there are too many, they have no owner, they fail checks for unrelated reasons, or they do not explain themselves. Fix the volume, the routing and the description, and the merge rate usually rises without any pressure.
The usual causes
Volume. Thirty open bot pull requests read as background noise. Nobody feels responsible for any single one.
No owner. If the pull request is assigned to nobody, it belongs to the team in general, which means nobody. See code owners for bot opened pull requests.
Red CI for the wrong reason. A flaky test on an unrelated file makes the pull request look broken. After two of these, people stop looking.
Thin explanation. "Bump x from 1.2 to 1.3" does not say why it matters. A reviewer cannot judge urgency or risk.
Unclear stakes. If every PR looks equally important, none feels urgent.
Six changes that help
- Cap the open count so the list stays short. See how many fix PRs to keep open.
- Route to owners using code owner files and assign the pull request to a named team.
- Order by risk. Put exploited and reachable issues first and say so in the title or labels.
- Write a good description: the vulnerability, the version jump, the evidence the fix works, and the rollback. The post on what a good fix PR description contains has a template.
- Fix flaky tests that fail bot branches. Treat that as part of the project.
- Set a review window, for example two working days, and escalate beyond it to the owning lead.
Measure instead of guessing
Track the merge rate, the median time to first review and the share closed unmerged. If a repository has a low merge rate and a high close rate, the tool settings for that repository probably do not match how the team works. Adjust scope before blaming people.
A note on culture
Do not turn the bot's pull requests into a leaderboard. Pressure to merge produces rubber stamping, and a reviewer who approves what they have not read is worse than one who waits. Make reading easy, and trust follows.
A quick audit you can run this week
Pull the last 30 closed bot pull requests. Sort them into merged, closed with a comment, and closed silently. Silent closures are the signal: nobody explained why, so nothing improves. Ask the closers one question each: what would have made this worth merging? Collect the answers and turn the top three into configuration changes. Most teams find that scope and ownership explain more than attitude does.
Where Safeguard fits
Safeguard's autonomous remediation opens fix pull requests with evidence attached and every category on Manual by default, and reachability analysis helps rank what needs attention first. You can try a free scan.
Quick check
Should we force reviewers to merge within a day?
A review window is fine, but forcing merges without reading invites rubber stamping. Keep the window realistic.
What is the first thing to change?
The open count and the ownership. Both are quick and remove the sense that the queue is nobody's job.
Last reviewed: 19 October 2026.
