Understanding and Managing Severity Levels in Clayton

In Clayton, the severity level indicates the seriousness or risk level of an issue within your codebase. It helps teams assess the potential impact on application security, stability, or maintainability and prioritize how urgently the issue needs to be addressed.
​

You can see the severity levels in every code review report that Clayton generates after a scan (whether it's a pull request or a revision) is completed.
​
​

You can filter issues by severity using the severity filter option, which helps you prioritise which issues to address first.
​

Issues classified as Critical in Clayton represent the highest level of risk and should be treated with urgency. These issues may expose sensitive data, allow unauthorised code execution, or introduce serious vulnerabilities that attackers could exploit. In addition to posing security threats, they often reflect deeply flawed code that significantly increases technical debt, making the application more fragile and harder to maintain over time. Because of the potential for severe consequences such as data breaches, system outages, or loss of user trust immediate action is strongly recommended. To help enforce this, Clayton blocks pull requests until all Critical issues are resolved, ensuring that high-risk code never reaches production unnoticed.​
​

Errors flagged by Clayton are critical indicators that parts of your code may compromise the stability, reliability, or maintainability of your application. While they might not pose immediate security risks, they can introduce bugs, unexpected behaviors, or performance issues if left unresolved.

These errors typically arise from coding practices or patterns that may seem harmless at first but can escalate into significant challenges as your codebase expands. Over time, unaddressed errors accumulate, leading to technical debt that makes the system harder to test, scale, or update.

To prevent long-term complications, it’s essential to prioritize and resolve these errors as part of your regular development process. Depending on your configured Protection Mode in Clayton, errors can block pull requests (PRs) from being promoted, reinforcing the importance of addressing them promptly.

By proactively managing errors, you maintain a healthier codebase, reduce technical debt, and minimize the need for large-scale refactoring in the future.
​

Warnings in Clayton highlight low-impact issues that carry minimal risk to the stability, security, or performance of your application. These issues are often stylistic or relate to best practices—such as inconsistent formatting, naming conventions, or minor inefficiencies—that don’t immediately affect how the code runs. While they don’t typically introduce bugs or vulnerabilities, addressing them can still improve code clarity, readability, and long-term maintainability. Because the rework required is generally minor, teams can choose to defer these fixes and handle them as part of regular code clean-up or refactoring efforts. Importantly, warnings do not block pull requests, allowing development to continue while keeping visibility on potential improvements.
​

Severity levels are clearly shown in every code review report—whether the scan was initiated by a pull request or triggered manually.

If you believe a severity level has been assigned inappropriately, you can update it as follows:

Note: Your ability to change severity levels may depend on your team's permission settings. Typically, only users with admin or maintainer roles can make these changes.