Auto-merge no longer adds PRs to the merge queue once requirements are met (since ~Sep 10, 2026) #209348
Replies: 3 comments 1 reply
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
This comment was marked as low quality.
This comment was marked as low quality.
|
Any updates here? Still happening for me. |

Uh oh!
There was an error while loading. Please reload this page.
🏷️ Discussion Type
Bug
Body
Since about September 10, 2026 (between ~15:20 UTC Sep 10 and ~06:40 UTC Sep 11), auto-merge no longer adds pull requests to the merge queue for us. Nothing in our configuration changed during that window.
Expected: an author turns on auto-merge ("Merge when ready") while the PR is still waiting on review or required checks. When the last requirement is met, GitHub adds the PR to the merge queue automatically. This worked reliably for us for months; the median delay was about 30 seconds.
Actual: the PR becomes fully mergeable and stays there with auto-merge still enabled, but it is never added to the queue:
mergeStateStatus: CLEANreviewDecision: APPROVEDautoMergeRequestis set, butisInMergeQueueisfalseSome PRs sat like this for hours or days, the longest for 8 days. Everything moves again as soon as someone disables auto-merge and clicks "Merge when ready" again (the PR is added to the queue at once), or calls the
enqueuePullRequestGraphQL mutation.Impact (one repo, ~260 merged PRs/week):
These cases came from 75 different authors.
Setup:
What we've ruled out:
autoMergeRequest.mergeMethodis alwaysSQUASH, even though only rebase is allowed. We tried to setREBASEthroughenablePullRequestAutoMerge, but GitHub storesSQUASHanyway. This was the same before the onset, so it probably isn't the cause.enqueuePullRequest) works every time; only the automatic step fails.Possibly related: cli/cli#13398, where
enablePullRequestAutoMergebehaves inconsistently when the merge queue is defined by a ruleset.Is anyone else seeing this since ~Sep 10? Did something change in how auto-merge hands PRs to rulesets-based merge queues?
All reactions