GitHub Merge Queue Pending Checks: Unblock Rollback PRs Waiting Forever (2026 Guide)
During incidents, the worst merge queue state is not always red failures. It is often endless Pending: rollback PR approved, but required checks never start or never finish.
This guide is a practical runbook for pending-check rollback delays in GitHub merge queue. You will learn how to tell workflow wiring issues from runner saturation, and how to unblock safely without weakening branch protection.
Table of contents
1. Quick decision table
| Symptom | Primary action | Why this works |
|---|---|---|
Required check stays Pending and never starts |
Verify workflow supports merge_group events |
Queue checks often run in merge-group context, not pull_request context. |
| Checks start very late during incident traffic | Inspect runner saturation and queue backlog | Capacity bottlenecks look like logic failures. |
| Checks restart after each queue update | Rebase rollback branch to latest protected tip and requeue | Fresh snapshot reduces repeated invalidation. |
| UI shows pending while logs are empty | Audit workflow-level if: guards and path filters |
Job conditions may unintentionally skip merge-group runs. |
| Incident pressure rising | Escalate via formal emergency path, avoid ad-hoc bypass | Preserves controls and audit trail while keeping decision explicit. |
2. Why pending checks happen in rollback queue entries
Most forever-pending rollback PRs fall into one of these buckets:
- Missing merge-group triggers: required workflows listen to
pull_requestbut notmerge_group. - Over-restrictive job guards: conditional logic skips jobs unless branch/event matches exact assumptions.
- Runner starvation: self-hosted runners or shared pools are saturated by long-running jobs.
- Snapshot churn: active base branch causes queue entry resets before checks complete.
- Hidden policy blockers: labels or environment approvals prevent readiness while UI emphasizes pending checks.
3. 5-minute pending-state triage
- Confirm rollback branch is rebased to the current protected target tip.
- Open required checks panel and note exact pending checks names.
- Inspect each workflow trigger for
merge_groupcoverage. - Check CI platform for runner queue depth and longest wait time.
- Verify no policy gate (labels, CODEOWNERS, env approvals) is unmet.
- Requeue with incident label and an explicit rollback-only scope note.
4. Queue-safe unblock workflow
Use this sequence when pending checks block rollback completion:
- Create a fresh rollback branch from protected tip.
- Apply only the necessary revert commit(s), no refactor or cleanup.
- Ensure required workflows include merge-group trigger support.
- Push rollback branch and open incident-labeled PR.
- Watch check start latency; if it exceeds expected SLO, inspect runner backlog.
- If queue resets repeatedly, re-sync branch and requeue immediately.
- Merge and run production verification checklist.
5. CLI command recipes
Prepare a fresh rollback branch
git fetch origin
git switch -c rollback/pending-checks origin/main
# Apply exact revert(s)
git push -u origin rollback/pending-checksRollback a merged PR (merge commit)
git fetch origin
git switch -c rollback/pr-incident origin/main
git log --first-parent --merges --oneline -n 30
git revert -m 1 <merge-hash>
git push -u origin rollback/pr-incidentRollback rebase/squash range as one commit
git fetch origin
git switch -c rollback/pr-incident origin/main
git revert --no-commit OLDEST^..NEWEST
git commit -m "Rollback PR due to incident: pending checks queue delay"
git push -u origin rollback/pr-incidentResolve conflicts and continue revert
# Resolve conflicts in files
git add .
git revert --continue
# If rollback target is wrong:
# git revert --abort6. Incident operations checklist
- Assign incident owner plus CI/queue observer.
- Mark rollback PR with incident priority label.
- Publish expected check start-time SLO in incident channel.
- Record every queue reset and check-retry event.
- Escalate workflow/runner owners if pending exceeds SLO.
- After merge, log exact rollback hash and validation result.
After stabilization, patch workflow triggers and runner capacity so the next rollback does not hit the same pending-state bottleneck.
7. FAQ
Can checks stay pending even though workflow files look correct?
Yes. Conditional job filters, environment rules, or runner quotas can still block job start despite valid trigger declarations.
How do I differentiate check failure from check non-start?
Failure has run logs and terminal status. Non-start usually shows pending with no run log and often points to trigger or scheduling issues.
Should we disable non-critical required checks during incidents?
Only if your governance model explicitly allows temporary policy change. Otherwise keep required checks stable and focus on rollback scope minimization.
How is this different from queue-stuck rollback triage?
This guide focuses on pending-check latency/non-start. For broader queue starvation and ordering delays, see Merge Queue Rollback Stuck Guide. If checks never start because workflow events are miswired, use Merge Queue merge_group Trigger Guide.
What if required checks fail after we fix pending-state issues?
Use Merge Queue Rollback Required Checks Guide to move from pending-state triage to direct failure remediation. If failures are intermittent rather than deterministic, use Flaky Required Checks Guide.