SonarQube Cloud Automatic Analysis queues GitHub checks but starts no CE task for PR #8

[manjoninc]

Product: SonarQube Cloud (sonarcloud.io) — Automatic Analysis — GitHub integration
Organization: manjoninc
Project key: manjoninc_buildcalc-pro
Repository: manjoninc/buildcalc-pro (private — we are not attaching source code, only API metadata; happy to grant temporary read access to a SonarSource engineer if needed)
Affected pull request: #8 (https://github.com/manjoninc/buildcalc-pro/pull/8), branch audit/structural-latex-f6 → main

Expected behavior

Automatic Analysis should behave the same way it has on every previous pull
request in this repository (#4, #5, #6, #7): when a commit is pushed to a PR
branch, the SonarQube Cloud GitHub App (app id 12526) creates a check-suite,
Compute Engine executes an analysis task within seconds, a “SonarCloud Code
Analysis” check-run is published on the commit, and the Quality Gate result
becomes available via both the GitHub check and the SonarCloud API.

Observed behavior

For PR #8, the SonarCloud GitHub App does create a check-suite immediately
(same second as the push), but the analysis pipeline never progresses past
that point. No check-run is ever published, no Compute Engine task is ever
created, and the PR’s Quality Gate status remains NONE indefinitely.

We reproduced this twice, on two different commits, roughly 24 minutes apart,
with identical results both times.

Immediate functional precedent (PR #7)

• Head commit: 20cad19c349622810d4ad06bd86ad6f6d9b46c38
• Check-suite: 89690165590, created by app id 12526 at 2026-08-27T17:46:01Z
• Check-run “SonarCloud Code Analysis”: completed / success, 2026-08-27T17:46:07Z–17:48:53Z
• Compute Engine task AaBEVr5E2A5dUYOn871I: status: SUCCESS, executionTimeMs: 3023
• Quality Gate: OK, all 5 new-code conditions OK
• Confirmed Automatic Analysis (no sonar-scanner step exists anywhere in this repository’s CI)
• Total elapsed time from push to completed check: ~3 minutes

This PR merged normally into main at 2026-08-27T17:56:34Z and main’s
own branch analysis completed a few seconds later — the binding and
Automatic Analysis pipeline were fully functional less than 24 hours before
the incident below.

Two failed attempts on PR #8

Attempt 1

• SHA: d7e8bfab52b65bad9b27a52c946a43529bedf4a4
• Check-suite: 89993871231, created by app id 12526 at 2026-08-28T19:38:44Z
• Result: status: queued, conclusion: null, latest_check_runs_count: 0 — unchanged when re-checked ~19 minutes later
• Zero check-run of any kind from the SonarCloud app on this commit
• Zero Compute Engine task for this PR anywhere in the project’s CE activity history
• SonarCloud’s project_pull_requests/list does register PR #8 (correct branch/base/title/url) but the entry has no status, commit, or analysisDate fields (contrast with PR #7’s fully populated entry)
• qualitygates/project_status?pullRequest=8 → {"status":"NONE","conditions":[],"periods":[]}
• project_analyses/search?branch=audit/structural-latex-f6 → error: “Component ‘manjoninc_buildcalc-pro’ on branch ‘audit/structural-latex-f6’ not found”

Attempt 2 (retrigger via a tree-identical empty commit, to rule out a one-off glitch — no code, test, or config changes)

• SHA: 67d0a8fee9ad6957faca845947d64de47a90be12 (parent = attempt 1’s SHA, identical tree)
• Check-suite: 89999026640, created by app id 12526 at 2026-08-28T20:02:44Z
• Result: identical to attempt 1 — status: queued, conclusion: null, latest_check_runs_count: 0, unchanged when re-checked ~54 minutes later
• GitHub Actions CI (our own workflow, unrelated to Sonar) completed successfully on this exact SHA, confirming the commit itself is healthy and reachable
• Same absence of any Compute Engine task, same Quality Gate: NONE, same “branch not found” from analysis search

We made no further retrigger attempts after attempt 2, per our own internal
change-control policy limiting this to two independent tries.

What we ruled out on our side

• Event delivery: ruled out — GitHub does notify the app (check-suite is created within the same second as the push, correctly associated with PR #8).
• Wrong project/PR identifier: ruled out — project key and PR number are confirmed correct and consistent with PR #7’s working case.
• Concurrent CI-based scanner conflicting with Automatic Analysis: ruled out — no sonar-scanner step exists in any of our GitHub Actions workflows; Automatic Analysis is our only integration.
• A one-off transient glitch: made less likely by the second, independent attempt failing identically ~24 minutes later.
• Our own CI: ruled out as a factor — GitHub Actions passed cleanly on both commits.

What we cannot determine from the public API

Why the pipeline stops between “check-suite created” and “Compute Engine
task submitted.” This requires visibility into SonarCloud’s internal
Automatic Analysis service logs for check-suite IDs 89993871231 and
89999026640, which we do not have access to.

Request

Could you please:

1. Inspect the internal Automatic Analysis / webhook processing logs for check-suite IDs 89993871231 and 89999026640 to determine why no Compute Engine task was ever created;
2. Confirm whether there was a platform-side incident affecting Automatic Analysis around 2026-08-28T19:38–20:03Z UTC;
3. Clear or resolve the two stuck queued check-suites on our behalf if that is something that can be done server-side;
4. If safe to do so, trigger the pending analysis for PR #8 (head 67d0a8fee9ad6957faca845947d64de47a90be12) server-side;
5. Let us know if the project/repository binding needs to be re-imported or re-linked, and if so, what steps we should take;
6. Confirm your diagnosis before we consider any change on our end (e.g., we are not planning to add a CI-based sonar-scanner step while Automatic Analysis is expected to keep working — we’d rather understand and fix the root cause than run two integration paths side by side).

Happy to provide any additional non-sensitive metadata you need. Thank you.

[manjoninc]

Read-only follow-up: local causes ruled out and one correction

We completed four additional read-only checks after filing the report:

1. SonarQube Cloud repository binding: Administration > General settings > Repository binding shows the project as Bound to manjoninc/buildcalc-pro, with that private repository selected as the Current binding. No setting was changed; Save/Cancel remained disabled.
2. GitHub App access: the installed SonarQubeCloud GitHub App has explicit access to the selected repository manjoninc/buildcalc-pro and the required read/write permissions for checks, commit statuses, and pull requests.
3. PR provenance: PR #8 is an internal PR. Its head repository and base repository are both manjoninc/buildcalc-pro; it is not from a fork or external contributor.
4. Submodules: the exact PR head tree contains no gitlink objects, and no .gitmodules file exists. This rules out the historical Automatic Analysis failure caused by inaccessible/broken submodules.

Correction to the original post

The original post said event delivery was ruled out because a queued check-suite was created immediately. After reviewing SonarSource’s own GitHub Checks announcement, that conclusion is too strong: Sonar states that check-suites are automatically created with QUEUED status for every repository accessible to the app, even when no analysis is launched:

PR analysis results are now displayed in the Checks tab of Pull Requests in GitHub

Hi SonarCloud users, We are happy to announce that we deployed a new feature to display the result of the Pull Request Analysis in one place inside the Checks tab of your Pull Request in GitHub What to expect ? As a result of the analysis, you’ll be able to see in the Checks tab for SonarCloud : Whether the result of the analysis is a success or not The number of open issues in your Pull Request if you have any The coverage and duplication information And a link to your PR in …

Therefore, the queued suites confirm app access, but do not prove that the PR webhook was successfully ingested by the Automatic Analysis pipeline.

The closest public precedent we found is a confirmed SonarQube Cloud incident where the WAF over-aggressively blocked some GitHub webhooks, causing Automatic Analysis to stop detecting PRs for only some projects:

Automatic Analysis stopped detecting new PRs

Hi SonarCloud Team, I have a few projects automatically imported from GitHub. Automated Analysis has been working ok for many months. Unfortunatel recently, for 2 of my projects, SonarCloud doesn’t detect new pull requests and doesn’t analyse them. The rest of the projects from the same organisation are working ok. After turning the “Automatic Analysis” off and on again, SonarCloud analysed the main branch, but pull requests were still undetected. Can you please help me with that issue?

Given the exact binding, explicit App access, internal PR provenance, absence of submodules, two independent failed attempts, and zero CE task/check-run, could you please also inspect webhook-ingestion/WAF records for the two timestamps and check-suite IDs in the original report? This now appears to be the most specific remaining failure boundary.

No additional retriggers, repository changes, CI/config changes, or PR state changes have been made.

[andres (Andrés García Solares)]

Hello @manjoninc, could you have a look at GitHub → repo Settings > Webhooks > Recent Deliveries for the SonarQube Cloud GitHub App (or Settings > GitHub Apps > SonarQubeCloud > Advanced, since it’s an App-level webhook) for PR #8’s check-suite events, and see:

• Whether GitHub shows a delivery attempt at all for check_suite/pull_request around 19:38:44Z / 20:02:44Z, and
• What HTTP response code Sonar’s endpoint returned (a non-2xx or timeout there would confirm it’s a delivery-side rejection, not a “never sent” case).