## TL;DR
Find the uncovered new lines in the SonarQube pull request view, add tests that exercise them (both sides of new conditionals), and re-run analysis. Deliberately exclude generated code via the sonar.coverage.exclusions property rather than gaming the number. The gate counts only lines added in the PR, so a small untested change can fail an otherwise well-tested repo.

## The error
```text
sonarqube: quality gate failed on new code coverage below 80 percent
```

## Steps to fix
1. Open the SonarQube project, go to the pull request or branch, and open the Coverage on New Code measure to list files with uncovered new lines.
   - Expected: a short list of files, each with specific uncovered lines highlighted.
2. For each file, open the source view and write tests covering the new branches - both the true and false sides of new conditionals, not just the happy path.
   - Expected: the new tests fail before the fix only if the code is wrong; here they just need to execute the lines.
3. If some new code is generated or genuinely untestable, add it to coverage exclusions deliberately through the sonar.coverage.exclusions property.
   - Expected: generated files stop counting against the metric.
4. Push and re-run the scanner.
   - Expected: the quality gate passes with new-code coverage at or above 80 percent.

## Use this when
- The SonarQube quality gate fails specifically on the new-code coverage condition.
- A PR adds untested lines to a repo that is otherwise well covered.
- You want the gate green without weakening it.

## Not for this skill when
- The gate fails on bugs, vulnerabilities, or duplications rather than coverage (different conditions, different fixes).
- Coverage shows 0 percent because the report was never uploaded (fix the report path first).
- The team has decided the threshold itself is wrong (that's a gate config change, not a coverage fix).

## Variant phrasings
- sonarqube quality gate coverage on new code failed
- PR blocked sonar coverage below 80 percent
- new code coverage gate red sonarqube
- sonarqube pull request coverage check failing

## Why it happens
SonarQube's default quality gate requires 80 percent coverage on new code. Coverage is measured per PR diff, so years of legacy coverage don't help - only the lines you touched count. A PR that adds a 20-line untested helper to a fully covered repo lands around 0 percent new-code coverage and fails the gate on its own.

## Edge cases
- Coverage shows 0 because the scanner ran before tests produced the report, or the report path is misconfigured - check the scanner logs for the report import.
- Monorepos with several coverage files need them merged before analysis, or only one module's coverage counts.
- Tiny PRs (a handful of lines) swing the percentage wildly - one uncovered line can mean 75 percent; that's the metric working as designed.
- Excluding files to hit the number without reason just hides risk; exclude only generated or truly untestable code.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xTOkTE05sN0EMsdHT4t0rw