We’ve got an update for anyone who’s seen SonarQube flag a “new” issue on a line nobody touched: this is fixed, and it’s already live on SonarQube Cloud, SonarQube Server, and SonarQube Community Build.
At a glance
-
Issues on lines you didn’t touch no longer count as New Code or fail your quality gate.
-
Works automatically wherever SCM data is available - no configuration needed.
-
Live now: SonarQube Cloud, and SonarQube Community Build 26.9.
-
Coming soon: SonarQube Server 2026.5
The details
What was happening?
New issues were showing up in New Code on lines that hadn’t changed in years. The cause was usually a legitimate change elsewhere (a compiler, dependency, or environment change, or an analyzer upgrade) not an actual edit to that code, but the old backdating logic didn’t account for it. The issue got today’s date and landed in New Code - sometimes blocking a quality gate, sometimes forcing a manual exception covering dozens or hundreds of issues at once.
What changed
Now, whenever SCM data is available for the line, SonarQube always sets the issue date to that line’s last commit date instead of the analysis date. If you changed the line, its commit date is recent, so the issue still counts as new code - that’s still working as intended. If you didn’t change the line, its commit date predates the new code period, so the issue lands in overall code instead. Without SCM data, the analysis date is still used, same as before.
Worth knowing
Note: while the always backdate behavior ensures old issues don’t fail the quality gate, a small number of legitimate new-code issues on unchanged lines (such as an unused-import or dead-code rule triggered by a change elsewhere in the file) may be excluded from new code too. This is a conscious trade-off: we’d rather prevent unrelated old-code issues from incorrectly failing your quality gate than catch every one of these edge cases.
If you run into a case where this causes real friction, tell us - we’re gathering concrete examples before defining any exceptions.
How can you get started?
No action needed — it’s already active wherever SCM data is available. See Issue date and backdating (SonarQube Cloud) or Issue date and backdating (SonarQube Community Build).
Would you be open to sharing an example where the trade-off above bites you? Drop a comment below or DM me.