> 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/quality-standards-administration/managing-rules/rule-update.md).

# If Sonar updates a rule

What might change regarding rules after a software update. This page is for SonarQube Server 2026.5.

Sonar developers continually re-evaluate Sonar rules to provide the best results. This process is evident in each release and means some rule-specific properties may change after a software update, even in a custom quality profile. This is normal and expected, and is no cause for alarm. The following are rule-specific properties that may change after a software update.

* **Software quality** (security, reliability, maintainability) updates to rules can occur. Changes to a rule’s software qualities will not be applied to issues previously raised by the rule until the project is reanalyzed.
* **Type** (bug, vulnerability, code smell) updates happen on occasion. When a rule type is updated, its value will update automatically in every profile that uses it. Although the rule will be updated, issues previously raised by the rule will remain the same. For example, if a rule transitioned from bug to code smell, the existing issues will retain their original bug type, and new issues will get the new type, code smell.
* **Severity**: Changes to a rule’s default severity will automatically be applied in quality profiles where the default severity was used. Although the rule will be updated, existing issues raised by the rule will remain the same. Note that it is possible to override a rule’s default severity in a profile, and your custom override should remain intact in your Quality Profile after the software update.
* **Tags** include two types: the default tags that come out of the box, and the custom tags added by administrators. When the default tags attached to a rule are updated in SonarQube Cloud, those changes will happen automatically. Custom tags associated with a rule will not change.
* **Key** can change but this is uncommon. Typically this happens in the rare case that, for whatever reason, a key that was non-normal and needs to be normalized. When the key of a rule is changed, related issues are updated as well, so that they remain related to the re-keyed rule.
* **Status** does not affect the operation of a rule and has no impact on its issues. There are three possible rule statuses: ready, beta, and deprecated. Sometimes, rules are first issued in beta status and then moved to ready. Most rules are in ready status; ready to be used in production. When Sonar developers realize that a rule no longer makes sense, they first deprecate the rule, then eventually drop it.

{% hint style="info" %}
You can sandbox the issues coming from a rule update to avoid abrupt and unexplained quality gate and pipeline failures and allow users to triage the sandboxed issues at their own pace. For more information, see [Sandboxing of issues](/sonarqube-server/discovering/code-analysis/sandboxing-of-issues.md).
{% endhint %}

## Related pages

* [SonarQube rules](/sonarqube-server/quality-standards-administration/managing-rules/rules.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/quality-standards-administration/managing-rules/rule-update.md?ask=<question>&goal=<user_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.