Roll out a new rule in stages: run it as a warning so it reports but does not fail builds, review the results, fix or baseline existing violations, then switch it to error. Announce the date in advance so developers are not surprised by a red build.
Why staging matters
A rule that fails every pull request on day one gets disabled by the first annoyed team. ESLint's configuration documentation addresses this directly: a rule set to "warn" is reported without affecting the exit code, and it says this is typically used when introducing a new rule that will eventually be set to "error". A rule set to "error" exits with code 1 when triggered, which is what makes it enforceable in CI, pre-commit checks and pull request merging.
The stages
| Stage | Setting | Exit code | Goal |
|---|---|---|---|
| 0 | Off, run in a branch | Unchanged | Check noise on the real code base |
| 1 | Warn | Unchanged | Make findings visible, collect feedback |
| 2 | Error on changed files | Fails | Stop new violations |
| 3 | Error everywhere | Fails | Full enforcement |
Roslyn analyzers use the same idea with different words. Their documented severity levels include Suggestion, Warning and Error, with the severity set per rule in an EditorConfig file.
Steps
- Pilot on a branch. Run the rule against the whole repository. Count results and read a sample.
- Fix the rule first. If a sample shows false positives, add test cases and fix the rule before any developer sees it.
- Enable as warn. Post in the team channel what the rule catches, why, and where to give feedback.
- Set a date. Pick a date for error mode, at least two weeks away, and write it in the rule's documentation.
- Deal with the backlog. Fix what is quick. Baseline what is not (see the related post on baselines).
- Promote to error. Change the severity in a reviewed commit.
- Watch for suppressions. A spike in disable comments in the first week is a signal about the rule, not about developers.
What to communicate
- What the rule flags, in one sentence.
- Why it matters, with one concrete example.
- How to fix it.
- How to suppress it, and what justification is expected.
- Who to ask.
Warnings people ignore
A warning stage with no end date becomes permanent, and a wall of warnings trains everyone to ignore output. Set a limit: if the rule is still in warn mode after a quarter, either promote it or remove it.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a pull request gate decides between passing and blocking. Your error stage is that same decision.
Quick check
Does a warning fail the build?
In ESLint, no. A rule at warn level is reported but does not affect the exit code. Only error level fails the run.
How long should the warning stage last?
Long enough to review the results and fix the rule, commonly a few weeks. Give it an end date so it does not become permanent.
Safeguard's scanning covers dependencies and SBOMs, and its reachability analysis helps show which findings your code can actually call. You can run a free scan on a repository.
Sources
Last reviewed: 19 October 2026.
