GitHub · Pull requests · Required status checks · Checked October 26, 2026

GitHub: a required check stays "Expected — Waiting for status to be reported"

A branch's protection or ruleset can require status checks before a pull request merges. A required check that has not reported on the pull request's latest commit shows in the merge box as "Expected — Waiting for status to be reported" (the words quoted in reports on GitHub's community forum), and the pull request is blocked until it reports and passes. GitHub's troubleshooting for required status checks gives the causes below; in the API the pull request's mergeable_state is blocked, and GraphQL's mergeStateStatus is BLOCKED (checked October 26, 2026).

GET /repos/OWNER/REPO/branches/BRANCH         → protection.required_status_checks.contexts
GET /repos/OWNER/REPO/rules/branches/BRANCH   → rule "required_status_checks": required_status_checks[].context
GET /repos/OWNER/REPO/commits/SHA/check-runs  → check_runs[].name
GET /repos/OWNER/REPO/commits/SHA/status      → statuses[].context

Why it never reports

The workflow was skipped: a workflow skipped by its path filters, its branch filters, or a skip instruction in the commit message (see [skip ci]) leaves its checks pending, and they block the merge. GitHub's example: a workflow that runs only when files under scripts change, and a pull request that changes a file in the repository root, blocked with "Waiting for status to be reported." GitHub's advice: avoid requiring workflows that can be skipped.
An event that does not count: checks from workflow jobs are evaluated for a pull request only when the run was triggered by push, pull_request, pull_request_review, pull_request_target, deployment or deployment_status. A run started with workflow_dispatch on the head branch does not satisfy the requirement, even when it passes on the head commit. This applies to workflow jobs, not to checks from an external GitHub App.
A merge conflict: workflows do not run on pull_request activity while the pull request has a merge conflict; it has to be resolved first. Workflows on pull_request_target still run (GitHub's events that trigger workflows).
A merge queue: a queue that requires a GitHub Actions check needs the workflow to run on the separate merge_group event; without it the check is not reported and the merge fails.
Fork runs awaiting approval: workflow runs from a contributor's pull request from a fork may need a maintainer with write access to approve them (Awaiting approval, then Approve workflows to run). Runs awaiting approval for more than 30 days expire and are marked as failed.
Another name: the requirement is by name. A check that reports under a different name, after a job was renamed for example, does not stand in for the required one, which stays expected. Compare the required names with the names reported on the head commit (the four reads above).
Another app: a requirement can name the GitHub App that must set the check (app_id in the branch's protection, integration_id in a ruleset). If the status is set by any other person or integration, merging is not allowed (GitHub's about protected branches), and GitHub says, for example, "Required status check "build" was not set by the expected GitHub App."
An earlier commit: required checks must pass on the latest commit; checks from earlier commits do not count. After a push, they have to report again.

What counts as passed

Conclusions: success, skipped and neutral satisfy a required check. A job skipped by a condition reports "Success" and does not block, even when it is required (GitHub's status checks reference). A check that was cancelled or went stale does not, and blocks until it runs again (see a cancelled check).
A job after a failed one: a job whose needs failed is skipped and may not block the merge; GitHub suggests always() with needs for required checks that depend on other jobs.
Same name, both kinds: when a check and a commit status have the same name and that name is required, both must pass.
The merge commit or the head: when the test merge commit has a status, it is the one that must pass ("Showing checks for the merge commit"); otherwise the head commit.
Up to date: when the rules require the branch to be up to date, merge or rebase the base branch into it first (see why a branch update was refused).

What to do

A skipped workflow: do not require a workflow that its filters can skip. Since a job skipped by a condition reports Success, a condition on the job, rather than a filter on the workflow, keeps the check reporting.
The event: trigger the workflow with pull_request (and merge_group for a merge queue).
The name or the app: make the required name match the name the check reports with, and the required app the one that sets it, in the branch's protection rule or ruleset.
A fork: approve its workflow runs after looking at the changes, especially under .github/workflows/.
Pushing to the branch directly: before the required checks have passed, a push to the protected branch is refused with GH006: Protected branch update failed and "Required status check "NAME" is failing".
Admins: by default the restrictions of a branch protection rule do not apply to people with admin permissions or to roles with the "bypass branch protections" permission, which is why some can merge while others wait.

In IntelliJ IDEA: "All required checks have passed", "Checks in progress…" and "Checks failed"

The GitHub pull requests built into IntelliJ IDEA show one line for the checks in a pull request's status, with a Details… link that lists them and opens one in the browser. In the source (checked October 30, 2026), the line is worked out from the checks on the last commit of the pull request, both commit statuses and check runs, with GitHub's isRequired for each (whether it is required to pass before merging this pull request):

"All required checks have passed" when every check marked required has succeeded. Checks that are not required are left out, so the line also reads this when none is required, whatever the others did.
Otherwise "Checks in progress, and some already failed…" when at least one check is still running and at least one has failed, "Checks in progress…" when one is running and none has failed, and "Checks failed" in every other case.
What counts as failed: a commit status in the state error, failure or expected, and a check run that concluded failure, cancelled, timed_out, stale, action_required, startup_failure or neutral. A check run that concluded skipped is counted as skipped, neither passed nor failed. So a required check that concluded neutral or skipped leaves the line at "Checks failed" when nothing is running, although GitHub counts both as passed for a required check (GitHub: About protected branches).
A required check with nothing on the commit is not among the checks the line counts, so the line can read "All required checks have passed" while GitHub still shows the check as "Expected — Waiting for status to be reported" and holds the merge back. With no check at all on the last commit, the line is not shown.

Source: GHPRMergeabilityStateBuilder.kt, CodeReviewDetailsStatusComponentFactory.kt, CollaborationToolsBundle.properties. The plugin below shows a check run that concluded neutral or skipped as Skipped, not failed, and names each required check that has not reported.

GitHub pull requests in IntelliJ IDEA

Pull Request Inbox for GitHub, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the checks on the head commit, both commit statuses and check runs, with links to them. When GitHub calls the pull request blocked, its merge checks say the rules of the target branch are not met yet (required reviews or required checks). Each required check that has not reported on the head commit is named there ("Required check "NAME" has not reported on this commit"), read from the target branch's protection and rulesets; not when the token was not shown every check on the commit. A fine-grained token is not shown check runs (see why checks are not shown). The review inbox, diffs and conversations are free; approving, commenting and merging are Pro (US$1.50 a month, with a 30-day trial).

GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitHub, Inc. or JetBrains.