> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-server/discovering/code-analysis/sandboxing-of-issues.md). # Sandboxing of issues Understanding how the Sandboxing of issues coming from SonarQube update works. This page is for SonarQube Server 2026.5. {% hint style="success" %} To set up the sandbox feature, see [Managing your project's quality gate](/sonarqube-server/project-administration/adjusting-analysis/changing-quality-gate-and-fudge-factor.md#setting-up-the-sandbox-feature-for-your-project) or [Quality standards](/sonarqube-server/instance-administration/analysis-functions/quality-standards.md#setting-up-the-sandbox-feature-at-the-instance-level). {% endhint %} 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. {% hint style="warning" %} 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. {% endhint %} {% hint style="info" %} To view the life cycle of issues if the Sandbox feature is used, see [SonarQube analysis process](/sonarqube-server/discovering/analysis-overview/process-steps.md#if-the-sandbox-feature-is-used). {% endhint %} ## 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. {% hint style="warning" %} 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. {% endhint %} For more information about quality profile management, see [Managing quality profiles](/sonarqube-server/quality-standards-administration/managing-quality-profiles.md). For more information about rule updates, see [If Sonar updates a rule](/sonarqube-server/quality-standards-administration/managing-rules/rule-update.md). ## 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](/sonarqube-server/instance-administration/analysis-functions/instance-mode.md)). {% hint style="warning" %} 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. {% endhint %} ### 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. {% hint style="info" %} If a large number of sandboxed issues become due for transition at the same time, SonarQube Server may take more than one day to transition them all. {% endhint %} ### 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 [Managing your project's quality gate](/sonarqube-server/project-administration/adjusting-analysis/changing-quality-gate-and-fudge-factor.md#setting-up-the-sandbox-feature-for-your-project) and [Quality standards](/sonarqube-server/instance-administration/analysis-functions/quality-standards.md#setting-up-the-sandbox-feature-at-the-instance-level). ## Related pages * [Triaging issues in Sandbox](/sonarqube-server/user-guide/issues/triaging-issues-in-sandbox.md) * [Managing your project's quality gate](/sonarqube-server/project-administration/adjusting-analysis/changing-quality-gate-and-fudge-factor.md#setting-up-the-sandbox-feature-for-your-project) * [Quality standards](/sonarqube-server/instance-administration/analysis-functions/quality-standards.md#setting-up-the-sandbox-feature-at-the-instance-level) * [If Sonar updates a rule](/sonarqube-server/quality-standards-administration/managing-rules/rule-update.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.sonarsource.com/sonarqube-server/discovering/code-analysis/sandboxing-of-issues.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.