Plan for two to six weeks of report only mode in a legacy monorepo, and end it when specific exit criteria are met, not when a date arrives. The right length depends on how noisy the first results are, how fast teams respond and how well you can tell old findings from new ones.
What report only mode is for
It has three jobs. It lets you measure false positives and tune rules before they can block anyone. It gives teams time to see the tool and ask questions. And it lets you build a baseline so that later gating applies only to new problems.
It is not a place to park the tool forever. A scanner that never blocks becomes background noise, and teams stop reading it.
Exit criteria that work
| Criterion | Example threshold |
|---|---|
| False positive review | A sample of findings reviewed by developers, with the rate understood |
| Baseline captured | All existing findings recorded as known, with a date |
| Ownership mapped | Nearly all findings route to a named team |
| Runtime acceptable | Pull request check finishes within the time budget you agreed |
| Escape route exists | A documented way to get a justified exception quickly |
Pick thresholds with the teams, write them down, and publish them on day one. People accept a gate they saw coming and resent one that appeared overnight.
Suggested stages
- Week one: run on a pilot directory, report to a channel, no comments on pull requests.
- Weeks two and three: add pull request comments for new findings in pilot areas. Collect complaints and tune.
- Weeks four and five: widen to most directories, still non blocking. Capture the baseline.
- Week six onward: block only on a narrow class, such as new critical findings with a fix available and known exploitation. Widen the rule later.
You may compress this for a small repository or stretch it for a large one. The shape matters more than the number.
Signs you should extend the period
- Developers report that many findings are wrong, and you cannot show otherwise.
- The check is slow enough that people open pull requests as drafts to avoid it.
- More than a few percent of findings have no owner.
- There is no exception process yet.
Signs you can move sooner
- The pilot teams ask when blocking starts, because they want protection from regressions.
- The false positive sample came back clean after tuning.
- The baseline is committed and new findings are easy to tell apart.
Announce the switch
Send one message a week before blocking starts: what will block, what will not, how to request an exception and who to contact. Include the rollback plan, because it shows you will not leave teams stuck.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a gate presents a decision on a pull request, and think about which rule you would turn on first.
Where Safeguard fits
Safeguard policies and gates let you move from observation to enforcement in steps, so you can start by reporting and tighten later. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Can we skip report only mode if the repository is small?
You can shorten it, but keep at least one pilot week. The false positive review is worth doing at any size.
Who decides when to start blocking?
A named owner, usually in security or platform engineering, agreed with engineering leads. Decide it before the pilot starts.
Last reviewed: 19 October 2026.
