Sandboxing of issues
Understanding how the Sandboxing of issues coming from SonarQube update works. This page is for SonarQube Server 2026.5.
To set up the sandbox feature, see Setting up the Sandbox feature for your project or Setting up the Sandbox feature at the instance level.
Some SonarQube updates may introduce new issues in your code on sections that have not been changed since the previous analysis. Such updates include Sonar analyzer improvements (improved rules), or changes to built-in quality profiles (addition of rules). This introduction of new issues may lead to abrupt and unexplained quality gate and pipeline failures, causing frustration and delays in releases.
To eliminate these pain points, you can enable the sandboxing of issues that come from SonarQube updates and fulfill preconfigured conditions. This way:
The sandboxed issues won’t impact your quality gate.
Users will be able to triage the sandboxed issues at their own pace.
Be aware that sandboxed issues can result in accumulation of debt if left unaddressed. Users should not postpone the triage and addressing of sandboxed issues for too long.
Scope of application
Sandboxing is exclusively active during the initial analysis following a version update and does not affect any later scans.
Specific updates that initiate sandboxing include:
Rule enhancements made by Sonar.
The addition of new rules to a built-in quality profile (such as Sonar way core). Any custom profiles which inherit from this built-in profile will receive updates automatically, which in turn triggers the sandboxing process.
Conversely, sandboxing will not be triggered by:
Manually inserting rules into a custom quality profile.
Utilizing a copy of a built-in quality profile instead of inheriting from it requires you to add rules manually after an upgrade. To ensure these updates are covered by sandboxing, you must use inheritance for your quality profiles.
For more information about quality profile management, see Managing quality profiles. For more information about rule updates, see If Sonar updates a rule.
Sandbox conditions
The way the conditions are applied depends on your instance mode (for more information about the instance mode, see Choosing a mode for your instance).
Sandboxing security and/or reliability issues can significantly elevate the risk of security breach, unpredictable behaviour and degraded performance of your software if the issues are not addressed.
MQR mode
Conditions for issue sandboxing are configured based on:
The software quality that the issue impacts.
The severity level of this impact.
An issue is sandboxed if:
Each impacted software quality fulfills a configured condition.
All configured conditions are fulfilled for at least one severity level for a given software quality.
Example 1
If you configure the following conditions:
The issue impacts maintainability with medium or low severity.
The issue impacts security with low severity.
then:
An issue impacting the maintainability with medium or low severity and the security with low severity, and with no impact on reliability will be sandboxed.
In all other cases, the issue will not be sandboxed.
Example 2
If you configure the following condition:
The issue impacts maintainability with medium or low severity.
then:
An issue impacting the maintainability with medium or low severity, and with no impact on security and reliability will be sandboxed.
In all other cases, the issue will not be sandboxed.
Standard Experience
Conditions for issue sandboxing are configured based on:
The issue type.
The issue’s severity level.
An issue is sandboxed if its type and severity level fulfill a configured condition.
Example
If you configure the following conditions:
Issue type is bugs with info, minor, or major severity.
Issue type is code smells with info or minor severity.
then:
A bug with info, minor, or major severity will be sandboxed.
A code smell with info or minor severity will be sandboxed.
Sandbox configuration levels
The instance admin can enable the Sandbox feature.
If Sandbox is enabled in their instance, the project admins can change the Sandbox status (on or off) for their project.
When enabling the Sandbox feature, the instance admin:
Sets the Sandbox’ default status (on or off) for all new and existing projects.
Configures the sandbox conditions and decides whether project admins are allowed to change them or not for their project.
Sets the number of days before sandboxed issues are automatically transitioned to Open status, and decides whether project admins are allowed to change it or not for their project.
Automatic transition of sandboxed issues to Open status
You can configure a number of days after which a sandboxed issue is automatically transitioned to Open status if nobody has triaged it. Instead of remaining invisible to your quality gate indefinitely, sandboxed issues move into your regular issue counts after the number of days you set.
Transition date calculation
When an issue enters the Sandbox, SonarQube Server calculates its transition date as the analysis date plus the configured number of days, and stores it on the issue. If the number of days is set to 0 (the default), no transition date is set, and the issue stays in the Sandbox until a user triages it.
Effects of the automatic transition to Open status
Once a day, SonarQube Server transitions sandboxed issues whose transition date has passed:
The issue’s status changes from In sandbox to Open, and its resolution is cleared.
The change is recorded in the issue’s changelog.
Measures are recomputed and the quality gate is re-evaluated, so the issue moves out of the Sandbox counters and into your regular issue counts. This can turn a passing quality gate into a failing one.
Webhooks and notifications are triggered, as they are for any other status change.
Applications (Developer edition and above) and portfolios (Enterprise edition and above) containing the updated projects are refreshed.
This applies to all branches and pull requests.
Rules for automatic transition to Open status
A manual triage always wins. If a user changes a sandboxed issue’s status (for example, by accepting it or marking it as a false positive) before its transition date, the pending automatic transition is canceled.
Changing the number of days only applies going forward. Issues already in the Sandbox keep the transition date they were given when they entered it. Lowering the setting doesn’t move the existing backlog to Open sooner.
Disabling the Sandbox feature doesn’t strand issues. If Sandbox is switched off at the instance or project level while issues are still waiting for their transition date, they’re still moved to Open automatically once that date passes.
Updating SonarQube Server doesn’t reset the clock. Transition dates that were already set aren’t pushed into the future by an update.
For more information about setting the number of days, see Setting up the Sandbox feature for your project and Setting up the Sandbox feature at the instance level.
Related pages
Last updated
Was this helpful?