Quality Gate condition scoped to Bug severity only. Is there a native solution?

Suggest new features
1

Hello,
We have what looks like a simple requirement for our Quality Gate:

  • Fail on any Bug with severity Critical/Blocker
  • Major/Minor bugs should NOT fail the gate
  • Fail on any Vulnerability, regardless of severity
  • Code Smells should never fail the gate, regardless of severity

We can’t find a built-in metric that isolates severity within a single issue type:

  • / count issues across Bugs + Vulnerabilities + Code Smells combined. Using them directly would also fail the gate on a Critical/Blocker-severity Code Smell, which we don’t want.
  • is scoped to Bugs only (A = 0 bugs … D = at least one critical bug, E = at least one blocker bug), so a condition like “Reliability Rating is worse than C” does correctly isolate bug severity from the other issue types. This looks like the closest built-in match, but it’s a rating threshold rather than an explicit count condition, and the UI flags it as non-compliant with Clean as You Code.
  • The Issues Search API ()returns the exact count, but that means a custom step outside the native Quality Gate to fail the CI pipeline.

My question is… is the Reliability Rating threshold actually the recommended pattern for this kind of requirement? Or do most teams end up handling “different pass/fail rules per issue type + severity” outside the Quality Gate entirely, via the API/a CI step? Curious what’s worked for others running this. We’re running SonarQube Community Edition v26.7.0.124771.

2

Hey @marcin_sonar, welcome to the Community!

For your requirements, I would say that the best solution is a condition the Reliability Rating worse than C, as you yourself have described. An alternative is a condition on Reliability Severity greater or equal than critical. This is equivalent to the condition on Reliability Rating.

You are right that this means that you will get a warning telling you that you’re not meeting our recommended standards, which basically means that you are removing conditions from our default set of conditions. The quality gate you’re proposing allows more than 0 issues on new code, the warning pops up because of that. If you are ok with the implications of allowing low-severity bugs to creep into the codebase, then you can disregard it.