## TL;DR
This log line means the quality gate ran and failed on new-code coverage - raise the coverage on the PR's new lines (or deliberately exclude generated code), then re-run. The message is a symptom; the fix is in the test coverage, not in the log line. If the team wants the gate advisory-only, turn off the scanner's quality-gate wait setting instead.

## The error
```text
ERROR: Coverage on New Code is less than 80.0
```

## Steps to fix
1. Confirm the context: check that the scanner step is configured to wait for the quality gate result - that wait setting is what turns a red gate into this ERROR line and a failed build.
   - Expected: the wait setting is on, so the build intentionally fails on a red gate.
2. Open the SonarQube pull request or branch page, find the Coverage on New Code metric, and list the uncovered new lines.
   - Expected: specific files and lines, not a vague shortfall.
3. Add tests covering those lines, or deliberately exclude generated code via the sonar.coverage.exclusions property, then push and re-run.
   - Expected: new-code coverage climbs toward the threshold.
4. Re-run the scanner step.
   - Expected: the log shows a passed quality gate instead of the ERROR line.

## Use this when
- CI logs show exactly this ERROR line from the SonarQube scanner step.
- The build is configured to wait for the quality gate.
- The failing condition is coverage, not bugs or vulnerabilities.

## Not for this skill when
- The ERROR names a different condition (e.g. reliability rating) - fix that condition instead.
- The scanner never reaches the gate check because analysis itself failed (fix the analysis error first).
- You want the gate to stop failing builds (turn off the wait setting; that's a policy choice).

## Variant phrasings
- sonarqube ERROR Coverage on New Code is less than
- scanner fails quality gate coverage new code
- coverage on new code less than 80 sonar error
- sonarqube build failed coverage condition

## Why it happens
When the scanner waits for the quality gate, a red gate becomes a build failure, and the scanner prints which condition failed. "Coverage on New Code is less than 80.0" is the condition text - the underlying cause is untested new lines in the PR diff. Teams see the ERROR in CI logs and chase the log line, but the line is just the messenger.

## Edge cases
- The number differs (e.g. "less than 75.0") when the project uses a custom gate - same fix, different threshold.
- Coverage reads 0 because the coverage report path is wrong or the report wasn't generated before the scan.
- Turning off the wait setting makes the build pass but the gate still red in SonarQube - fine if the team chose advisory mode, bad if nobody noticed.

## Provenance

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