Using SonarQube’s Leak Period to Focus on New Code Issues

Problem: Historic debt masks new regressions

When a project has accumulated technical debt, the total issue count can overwhelm the quality gate. Teams spend time fixing old violations instead of preventing new ones, which makes it hard to see whether recent changes are improving or degrading code quality.

Thesis: Leak Period (New Code) isolates recent issues

SonarQube’s Leak Period (also called New Code) lets you define a baseline—such as the previous version, a specific date, or a branch analysis—so that only issues introduced after that point are counted toward the quality gate. This shifts the focus from historic debt to fresh regressions.

Understanding the leak period options

• Previous version: Uses the last analyzed version as the baseline.
• Date: You pick a calendar date; everything analyzed after that date is considered new.
• Branch analysis: When using SonarQube’s branch feature, the leak period can be tied to the analysis of a specific branch.

The chosen value is stored server‑side and applied to all subsequent analyses unless overridden by analysis parameters.

Configuring the leak period

Via the SonarQube UI

You need Project Administrator permissions.

1. Open the project in SonarQube.
2. Navigate to Project Settings → General Settings → Leak Period.
3. Select one of the three options (Previous version, Date, or Branch analysis) and save.

Via analysis parameters (Maven example)

If you want to override the server setting for a single run, add the sonar.leak.period property to the Maven command. You need read access to the project and the ability to execute the build.

mvn clean verify sonar:sonar -Dsonar.leak.period=previous_version

Replace previous_version with date:2026-09-01 or branch:feature/login as needed.
Verifying that the leak period works

  
Run the analysis with your chosen setting.
  
After completion, open the project and go to Issues.
  
Select the New Code filter at the top of the issue list.
  
Confirm that only violations introduced after the baseline appear.
  
Check the Quality Gate dashboard: the counts for bugs, vulnerabilities, and code smells under the “New Code” section should match the numbers shown in the New Code issue list.

If the numbers differ, revisit the leak period setting and ensure the baseline is correct.
Trade‑offs and limitations

  
Baseline accuracy: If the baseline version is misidentified (e.g., you accidentally pick an older snapshot), existing issues may be labeled as new, inflating the metric and potentially causing false gate failures.
  
Retroactive re‑classification: Changing the leak period after data has been collected re‑classifies all past issues, which can disrupt historical trends and dashboard widgets that rely on the new‑code distinction.
  
Branch inheritance: When using branch analysis, a feature branch inherits the parent branch’s leak period unless you explicitly override it, which can lead to confusion if you expect a different baseline for the branch.

Actionable checklist

  
Decide on the baseline that best represents “code before we start caring about new issues” (usually the last released version).
  
Set the leak period in the UI or via sonar.leak.period in your CI pipeline.
  
Run a fresh analysis and verify the New Code filter shows only post‑baseline violations.
  
Monitor the Quality Gate; adjust the baseline only after communicating the impact to the team.
  
Document the chosen baseline in your project’s README or wiki so future maintainers understand why the New Code metric looks the way it does.