SonarQube analysis returns SUCCESS but reports zero issues

The problem: scanner succeeds, but the dashboard shows zero issues

You run the SonarQube scanner for a Java project. The command exits with status 0, the log ends with "Analysis successful" or "BUILD SUCCESS", and the quality gate may even pass. When you open the project in SonarQube, however, the Issues page shows zero issues, or the New Code view shows nothing despite code that should violate activated rules.

A successful exit code only means the scanner finished and uploaded its report. It does not guarantee that the scanner read your source files, that type-resolution rules had the compiled classes they need, or that new-code detection had a baseline to compare against.

Use this guide when analysis completes successfully but expected issues are missing. It covers source exclusions, compiled-bytecode dependencies, New Code Period configuration, and missing metric reports.

Likely causes and matching checks

Observable condition	Likely cause	Where to look
Scanner SUCCESS, zero issues across all code	Source directories are excluded, or no rules are activated in the project quality profile	sonar.exclusions, sonar.inclusions, project quality profile
Issues on old code but none on new code	New Code Period points to a previous version or branch with no prior analysis	Project settings > New Code Period
Some rules missing, especially bugs requiring type resolution	Compiled classes and dependency JARs are not on the analyzer classpath	Build command, sonar.java.binaries, dependency path
Quality Gate passes but coverage or duplication conditions are empty	Coverage or duplication reports were never generated or supplied to the scanner	Quality Gate details, scanner input properties

Ordered diagnostic checks

1. Confirm which source files the scanner actually read. Re-run analysis with verbose logging. On the command line, from the project root:

   # Requires read access to the source tree and execute permission for the scanner.
   # Replace  with your SonarQube project key.
   mvn clean verify sonar:sonar \
     -Dsonar.projectKey= \
     -Dsonar.verbose=true
   

   Expected check: look for Analyzing ... lines. If a package such as com.example.service never appears, the scanner did not read those files.

   Risk: mvn clean verify rebuilds modules and takes longer than running sonar:sonar alone, but it ensures compiled bytecode and dependencies are available to the analyzer.

2. Inspect exclusion and inclusion patterns. Open sonar-project.properties or the POM and compare sonar.exclusions against the actual directory tree:

   find src/main/java -type f -name "*.java"
   

   Patterns are case-sensitive on some operating systems. A pattern such as **/generated/** can unintentionally omit a directory that contains hand-written code.

3. Verify the quality profile. Open the project's quality profile and confirm the rules you expect are activated, not just inherited in a disabled state.

4. Check the Java classpath. Rules that require type resolution skip symbols when compiled classes or third-party JARs are missing. For Maven, prefer:

   mvn clean verify sonar:sonar
   

   over running sonar:sonar without a preceding build, because the latter may analyze stale or missing bytecode.

5. Check New Code Period. If the period is set to "Previous version" and no previous analysis exists, there is no baseline for new-code detection. Change it to a branch or version that already has an analysis, or to a period appropriate for your SonarQube edition.

6. Inspect Quality Gate details. Open the Quality Gate conditions for the project. If a condition references coverage or duplication but the metric shows no value, the report was never generated or supplied to the scanner.

Fixes matched to each finding

• Exclusions removed intended code. Edit sonar.exclusions so target source paths are included, or move the pattern to sonar.inclusions only if you intend an allow-list. Re-run analysis and confirm the previously missing files appear in verbose Analyzing output.

• Missing compiled bytecode. Rebuild before analysis and pass compiled classes and dependency JARs. For Maven, use mvn clean verify sonar:sonar. For Gradle, ensure the SonarQube plugin runs after compileJava and test so class files and test reports exist.

• No New Code baseline. Set New Code Period to a specific branch or previous version that already has an analysis, then re-run. On SonarQube Community Edition, branch analysis is limited; branch-specific New Code Period settings may not apply as expected.

• Missing metric reports. Generate coverage reports (for example, JaCoCo) and duplication reports before analysis, and pass their paths to the scanner. Verify the metric appears in Quality Gate details after re-analysis.

Only change scanner properties or rebuild configuration when a check identifies a matching cause. Reverting a property change is the rollback: restore the previous value in sonar-project.properties or the POM and re-run analysis to confirm behavior returns to its prior state.

Escalation criteria

Escalate to SonarSource community channels or your edition's support when:

• Source files appear in verbose output, rules are activated, and New Code Period has a baseline, but expected issues still do not appear after re-analysis.
• The scanner returns a non-zero exit code or crashes on retry.
• You suspect a defect in the Java analyzer plugin bundled with your SonarQube edition.

Do not modify the SonarQube database directly to force issue visibility. Use the UI or Web API.

Limitations and verification

• Java analyzer capabilities depend on the plugin version bundled with your SonarQube edition.
• Exclusion patterns are case-sensitive on some operating systems and behavior can differ between scanner versions.
• SonarQube Community Edition has limited branch analysis; branch-specific New Code Period settings may not apply as expected.
• This guide describes well-established scanner behavior. Confirm menu paths and property names against your installed version before changing CI configuration.

Practical verification: run analysis with -Dsonar.verbose=true, confirm expected files appear in Analyzing entries, open the Issues page with all filters removed, and check Quality Gate details for conditions with no computed value.