Hi David,
Welcome to the Community! Thanks for providing the CE log. After analyzing the log here are some findings:
Global webhook timing out on every analysis
The global webhook Tooling Webhook Listener is pointing to an endpoint that appears to be unreachable, this adds a 10-second stall to every single analysis task. This used 275 minutes of CE worker capacity per 14.5-hour window.
To resolve this, go to Administration > Configuration > Webhooks and either:
- Remove the Tooling Webhook Listener webhook entirely, or
- Update the URL to the correct production endpoint if the webhook consumer is intentional.
Portfolio recalculation frequency
Your SonarQube instance currently has the sonar.portfolios.recompute.hours property unset, which means every completed analysis immediately triggers a portfolio refresh for all
portfolios that include that project. In your case this generated 235 All_Projects portfolio refresh tasks in a ~14 hour window, roughly one every 4 minutes. Each refresh occupies a CE worker for 10–38 seconds, and CE workers rotate between analysis and portfolio refresh tasks, so this is a meaningful ongoing drain on your available capacity.
To reduce this load, go to Administration > General Settings > Portfolios > Portfolio Calculation Hours and enter the hours at which you want portfolios to recompute (for example 0,6,12,18 for four times daily, or 22 for once nightly). Once a value is set, SonarQube will stop triggering a portfolio refresh after every individual analysis and instead batch the recalculation at the configured times. Portfolio data will be slightly behind between recalculation windows, so choose a schedule that fits your reporting needs.
Large project scan volume
Your android project has approximately 21,900 components and is being scanned around 47 times in a 14-hour window, roughly once every 18 minutes. Individual android scans are taking between 24 seconds and 7 minutes each. This is expected behavior for a project of this size, but the combination of large task duration and high scan frequency means one CE worker is frequently occupied for several minutes at a stretch, reducing throughput for other teams.
A few things worth reviewing:
- If the android codebase is a monorepo, splitting it into smaller SonarQube projects would reduce per-task duration and allow the work to be distributed across workers rather than serialised.
- If main branch scans are triggered more frequently than needed, reducing that frequency or scheduling them during off-peak hours would help.
These changes should significantly reduce the pressure on your CE workers without requiring additional infrastructure.
Hope that helps.
Stevan