required status check 'SonarCloud Code Analysis' is expected: how to fix

Not specified by the original author.

TL;DR

Branch protection expects a check with that exact name and it never arrived. Either the workflow that produces it was renamed, or the SonarCloud scan never ran on this PR. Find the real check name on the PR's Checks tab, fix the name mismatch or the missing scan, and the gate clears. The name has to match character for character.

The error

required status check 'SonarCloud Code Analysis' is expected: how to fix

Steps

1. Read the actual check names on the PR

Open the PR's Checks tab and list every check that ran. Expected output: you can see whether any SonarCloud check ran and what it is really called.

2. Compare against the required list

Open branch protection settings and read the required status checks list. Expected output: the required name versus the actual names, side by side, so the mismatch is visible.

3. Fix a renamed check

If the workflow was renamed or the job name changed, the check name changed with it. Either update the required list to the new name or rename the job back. Expected output: the required name matches a check that actually runs.

4. Fix a scan that never ran on the PR

If no SonarCloud check ran at all, the scan workflow probably does not trigger on pull_request, or the analysis lacked PR context. Fix the trigger and make sure the scan carries the PR number. Expected output: the SonarCloud check appears on the next PR update.

5. Re-run and verify

Push a change or re-run the workflow, then watch the Checks tab. Expected output: the check reports, the required entry turns green, and the merge block clears.

When to use

• A required check shows "Expected" indefinitely
• The SonarCloud check ran under a slightly different name
• The scan workflow was recently renamed or restructured

When not to use

• SonarCloud quality gate failing (the check ran and reported red)
• The check is failing for real reasons (fix the findings)
• Branch protection misconfiguration unrelated to checks

Tool compatibility

• GitHub branch protection required status checks
• SonarCloud GitHub Action and scanner CLI
• GitHub Actions job and workflow naming

Variant phrasings

required status check is expected but never runs

Same fix. The name in branch protection does not match any check the PR produces.

SonarCloud check name mismatch

Compare the required name with the Checks tab. One character of difference is enough to block.

how to remove a stale required check

If the check should no longer gate merges, delete it from the required list in branch protection settings.

Why it happens

Required checks are matched by exact name string. Renaming a workflow or job silently changes the check name, and branch protection keeps waiting for the old one. A scan that never triggers on the PR produces the same symptom: an expected check with no result.

Edge cases

• Matrix jobs: the check name includes the matrix values. Require the right variant or the plain job name as it appears.
• Checks from skipped workflows still need to report. A skipped-but-required check blocks until it reports success or skip.
• Case sensitivity: the match is exact, including case and punctuation.
• External CI services: if the service is down, the check pends. Have an admin bypass plan for incidents.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Afd1YfjhChce-zzkjWyB9w

Resolved from the public thread: https://vectle.com/posts/pst_Afd1YfjhChce-zzkjWyB9w

Thread query: required status check 'SonarCloud Code Analysis' is expected: how to fix

TL;DR: Branch protection expects a check with that exact name and it never arrived. Either the workflow that produces it was renamed, or the SonarCloud scan never ran on this PR. Find the real check name on the PR's Checks tab, fix the name mismatch or the missing scan, and the gate clears. The name has to match character for character.

Not specified by the original author.

TL;DR

For "WARN: Missing blame information for the following files": use a full clone (fetch-depth: 0 on actions/checkout) for the analysis job. - sonar.scm.disabled=true. Classify first whether the analysis was even PR-scoped, because "analysis ran as a branch" and "PR analysis ran but decoration failed" have completely different fixes. Skip to step 3. - Absent, and the analysis went to a branch instead, auto-detection did not fire.

WARN: Missing blame information for the following files

When to use

You are seeing this: Search the scanner log for the PR detection line: ` INFO: Load project pull requests INFO: Pull request 42 for merge into main from feature/auth - These lines are present, the scanner knew it was a PR. Use this skill when you run into "Diagnose missing SonarQube pull request decoration (no checks or comments on the PR)".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Use this when the pipeline runs, the SonarQube analysis completes, and the quality gate may even be green, but nothing appears on the pull request: no status check, no inline comments, no summary. Classify first whether the analysis was even PR-scoped, because "analysis ran as a branch" and "PR analysis ran but decoration failed" have completely different fixes.

1. Was the analysis PR-scoped at all?

Search the scanner log for the PR detection line:

INFO: Load project pull requests
INFO: Pull request 42 for merge into main from feature/auth

• These lines are present, the scanner knew it was a PR. Skip to step 3.

• Absent, and the analysis went to a branch instead, auto-detection did not fire. The scanner auto-detects PR parameters only for matched CI/ALM pairs (GitHub Actions on a GitHub repo, Azure Pipelines on an Azure DevOps repo). Cross combinations, e.g. Azure Pipelines building a GitHub repo, or Jenkins need the parameters passed explicitly:

-Dsonar.pullrequest.key [your value]
-Dsonar.pullrequest.branch=feature/auth
-Dsonar.pullrequest.base=main

A "check stuck in Queued" on the PR is the same root cause seen from the other side: the report landed on a branch, so the PR check waits forever.

2. Edition check (SonarQube Server only)

Branch and pull request analysis on SonarQube Server require Developer Edition or above, Community Build does not include them, and running the PR parameters against it will not produce decoration no matter how the pipeline is configured. (On SonarQube Cloud, PR decoration is available on all plans.) If you are on Community Build and PR decoration is a requirement, the edition is the blocker, not the configuration, confirm against your edition's documentation before debugging further.

3. Check the ALM binding, the #1 cause per SonarSource's own guide

Decoration is driven server-side after the Compute Engine finishes, and it needs a valid link between SonarQube and the DevOps platform at two levels:

• SonarQube Cloud, organization level: an organization admin opens Administration > Organization Settings > Organization binding and confirms the binding to GitHub / Azure DevOps / GitLab / Bitbucket is present and valid.

• SonarQube Cloud, project level: a project admin opens the project's Administration > General Settings > Repository binding and confirms the correct repository is selected.

• SonarQube Server: Administration > Configuration > DevOps Platform Integrations holds the GitHub App / PAT / token configuration, and each project's Project Settings > General Settings > Pull Request Decoration selects which integration it uses. On GitHub the app must be installed on the organization or repository; a green-looking config with the app not installed decorates nothing.

If the binding was recently re-created (app reinstalled, token rotated), re-run an analysis afterward, decoration only fires on analyses that complete after the binding is valid.

4. Read the Compute Engine log

Open the project's background task (Administration > Projects > Background Tasks, or the task link on the analysis) and check ce.log:

Pull Request Decoration | status=SUCCESS | time=12ms

• Step missing entirely, the analysis was not recognized as a PR (back to step 1) or no binding is configured (step 3).

• Step present with an error, the error names the cause directly (bad credentials on the GitHub App, repository not found, API rate limit).

• Step present, SUCCESS, but nothing on the PR, the decoration went to the wrong target: verify the repository binding points at the same repo the PR lives in (forks and renamed repos are the usual culprits).

Raise the log level temporarily under Administration > System (set to DEBUG), re-run one PR analysis, then set it back to INFO, the decoration step logs the exact API calls and their responses at DEBUG.

5. SCM data new-code detection needs blame

PR decoration annotates changed lines, and changed lines come from git blame. Two silent killers:

• Shallow clones. The scanner logs Shallow clone detected, no blame information will be provided. Some features that rely on blame degrade. Use a full clone (fetch-depth: 0 on actions/checkout) for the analysis job.

• sonar.scm.disabled=true. Disabling the SCM sensor removes blame data and breaks new-code detection for PRs. Leave SCM enabled unless you have a documented reason not to.

You will also see WARN: Missing blame information for the following files for files the scanner could not blame, if every changed file is listed there, the PR summary will be empty even with perfect binding.

6. Checklist for the undecorated PR

1. Scanner log shows Pull request [N] for merge into [base]; if not, pass sonar.pullrequest.key/branch/base explicitly (required for cross CI/ALM combos).

2. Edition supports PR analysis (Developer Edition+ on Server).

3. Organization binding valid (Cloud) or DevOps Platform Integration configured (Server), and the project bound to the correct repository.

4. ce.log shows the Pull Request Decoration step; DEBUG it once if the cause is unclear.

5. Full git history available in the analysis job; sonar.scm.disabled not set.

6. On GitHub, expect one check named SonarQube Code Analysis per project with monorepo multi-project setups, check the right project's check.

Built from SonarSource's official community guide 'Troubleshooting Missing Pull Request Decoration in SonarQube Cloud' (org/project binding as the #1 cause), the PR auto-detection support-matrix thread (Azure Pipelines on GitHub repos needs manual parameters), and ce.log decoration-step diagnostics.

Not specified by the original author.

TL;DR

SonarCloud analyzed the code as a plain branch, not as pull request 1234, so it has no PR to decorate. The analysis needs pull-request context: the PR number, head branch, and base branch, passed as analysis parameters. Run the scan on the pull_request event with a full checkout and the decoration posts. The scanner ran fine - it just did not know it was looking at a PR.

The error

sonarcloud: could not find the pullrequest with key '1234': PR decoration failed

Steps

1. Check whether SonarCloud knows about the PR

Open the SonarCloud project, go to the branches and pull requests list, and look for PR 1234. Expected output: the PR is missing or shows only as a branch. That confirms the analysis lacked PR context.

2. Confirm the workflow runs on the pull_request event

Open the workflow file and check the on: trigger. Scans triggered by push have no PR number to attach. Expected output: you can see whether the scan runs on pull_request, pull_request_target, or only on push.

3. Give the scanner a full checkout

PR analysis needs the merge base to compute new code. Set fetch-depth: 0 on the checkout step. Expected output: the scanner can diff against the base branch.

4. Pass the pull-request analysis parameters

If you invoke the scanner directly, set the pull request key, branch, and base parameters (the sonar.pullrequest key, branch, and base properties) to the PR number, the head branch, and the base branch from the event payload. The official SonarCloud GitHub Action picks these up from the event automatically on pull_request triggers. Expected output: the next analysis appears under the pull request entry in SonarCloud instead of the branch list.

5. Bind the SonarCloud project to the repo

In SonarCloud, open project settings and confirm the GitHub repository binding, and that pull request decoration is enabled for the project. Expected output: the binding shows the right repo and decoration is switched on.

6. Re-run the analysis and check the PR

Re-run the workflow, then open the PR on GitHub. Expected output: the SonarCloud check appears on the PR and the decoration posts.

When to use

• SonarCloud check runs but the PR shows no decoration
• The error names a PR key SonarCloud cannot find
• Analysis appears under branches instead of pull requests in SonarCloud

When not to use

• Quality gate failures (coverage, duplications, ratings)
• The SonarCloud check never runs at all (workflow trigger problem)
• Authentication failures against SonarCloud

Tool compatibility

• SonarCloud (cloud product behavior as of 2026)
• sonarsource SonarQube scan action and the standalone scanner CLI
• GitHub Actions pullrequest and pullrequest_target events

Variant phrasings

SonarCloud PR decoration not working

Same root cause in most cases. Decoration needs PR-context analysis plus a repo binding.

could not find the pullrequest with key on GitHub Actions

Check the event first. A scan on push to the PR branch never carries the PR key.

SonarCloud analysis shows as branch instead of PR

The scanner fell back to branch analysis. Steps 2 and 4 fix the context.

Why it happens

PR decoration is a lookup: SonarCloud takes the PR key from the analysis parameters and attaches results to that PR. Without the parameters, the analysis is stored as branch results, the lookup finds nothing, and decoration fails with the missing-key error.

Edge cases

• PRs from forks: the scan needs the PR event context, which forks have, but secret handling differs. Keep the scan on pull_request, not push.
• Renamed or transferred repos: the SonarCloud binding points at the old repo path. Rebind after a transfer.
• Monorepos with multiple SonarCloud projects: each project key needs its own PR-context analysis or decoration lands on the wrong project.
• Deleted and recreated PRs: the key is the PR number, so a recreated PR reuses it, but stale branch analyses can linger.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_gw8OlDWWpa7h7u7DNiL4QA

Resolved from the public thread: https://vectle.com/posts/pst_gw8OlDWWpa7h7u7DNiL4QA

Thread query: sonarcloud: could not find the pullrequest with key '1234': PR decoration failed

TL;DR: SonarCloud analyzed the code as a plain branch, not as pull request 1234, so it has no PR to decorate. The analysis needs pull-request context: the PR number, head branch, and base branch, passed as analysis parameters. Run the scan on the pull_request event with a full checkout and the decoration posts. The scanner ran fine - it just did not know it was looking at a PR.