A required check that reports success, skipped or neutral satisfies GitHub's merge rule. A check that never reports is different: pending is not an accepted state, so the pull request waits. Path filters and duplicate job names are the usual causes. Test on a throwaway pull request before you rely on the rule.
What GitHub accepts
GitHub's protected branch documentation says required status checks must report a successful, skipped or neutral status before changes can merge. Pending is not on that list. That is the whole puzzle in one sentence.
A workflow that is skipped by a path filter may never create the check at all, and then the required name sits at expected or pending. A job skipped inside a workflow that did start, by contrast, reports as skipped and passes.
Common causes of a stuck pull request
- A workflow filtered by paths, so a docs-only change never starts it, while the rule requires its job.
- Two workflows with the same job name. GitHub warns that duplicate job names across workflows can give ambiguous results and block merges.
- A renamed job, where the rule still lists the old name.
- A check that comes from an app you uninstalled.
None of these are security failures. They are the kind of friction that pushes teams to turn the rule off, which is the real risk.
How to debug it in ten minutes
- Open the blocked pull request and read the list of required checks, noting any that show as expected.
- Compare each required name with the job names in your workflow files.
- Search for duplicate job names across workflows.
- For path filtered workflows, either move the filter into a job level condition so the job reports skipped, or add a lightweight always running job that the rule requires.
- Open a throwaway pull request that touches only a doc file and confirm it can merge.
Step 5 matters because the documentation does not walk through path filters. Treat behavior on your repository as the source of truth and write down what you observe.
Keep the rule strict
Resist the urge to drop the required check. A stuck pull request is annoying for an hour. A missing gate can stay unnoticed for a year. Fix the check so it always reports, and keep the list of required checks short and named after what they prove, such as unit tests, dependency scan and secret scan.
Where Safeguard fits
Safeguard scans dependencies and builds an SBOM, and its policies and gates can block a pull request that adds a known-vulnerable package. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Step through the gate and note how a check result decides whether the merge button unlocks.
Click through it at your own pace, or open it full screen.
Quick check
Is skipped the same as passed?
For the merge rule, GitHub lists skipped as an accepted state alongside success and neutral. It does not mean the code was checked.
Where do I see why a check is missing?
On the pull request, look for checks marked expected, then compare names with your workflow job names.
Sources
Last reviewed: 19 October 2026.
