Scheduled scans for long-running repositories

Scheduled scans are the proactive half of nreactive. Where runtime monitoring reacts to errors that already fired in production, a scan reads your repository on a cadence and asks whether there's anything latent waiting to fire. This post is a practical guide to running scheduled scans on codebases that have been around for a while.

What a scan does

A scan fires on a cron-style schedule you configure per app. When it runs, it lists source files via your VCS, filters and prioritizes them, picks the top N within your plan's budget, fetches their contents, compresses them, and asks the model to produce up to five high-signal suggestions. Each suggestion comes with a verbatim before/after snippet. The patcher attempts to apply all of them to a new branch, and if at least one lands, a single PR is opened bundling the surviving changes.

The whole pipeline is designed to produce zero PRs on a clean run. If the model finds nothing that clears its strict review bar, the scan closes with "no suggestions found" and the dashboard records the event. No noise.

Budget and scope

The scan reads at most 25 files on a Pro plan, 15 on Free. Files are capped at 60 KB each to prevent any single generated file from starving the budget. The prioritization algorithm favours API routes, pages, middleware, and services over UI components; depth and size add small penalties; files touched in the last 30 days jump to the front regardless of base weight.

Out of those 25 files, the model produces up to five suggestions. The resulting PR can touch multiple files — suggestions targeting the same file are chained through the patcher in order — but the numeric upper bound stays bounded and predictable.

Cadence options

Weekly is the default and what we recommend for most teams. A daily scan is available for Pro and makes sense on actively-developed services where you want fast feedback on new code. Less frequent than weekly probably isn't worth setting up — the overhead of context-switching into a scan PR that's been waiting two weeks is higher than the signal it adds.

Cron strings aren't exposed directly. Instead you pick a frequency (daily, weekly, off), and the scheduler picks a time-of-day that spreads load across its user base. If you need a specific hour — say, right after your weekly deploy — reach out via contact.

Adopting scans on a legacy repo

A repo with ten years of history will overwhelm a fresh scan if you let it run wide. Two tactics keep the first few runs productive:

• Aggressive deny list. Start by excluding the directories where you know AI changes would be a distraction: generated code, vendored dependencies, deprecated modules you're planning to delete. You can always loosen later.
• Lean on recency. The 30-day recency bias does a lot of work on legacy repos. A file that hasn't been touched in three years is unlikely to have a latent bug nobody cared about — and if it does, runtime monitoring will surface it.

Run the first scan, read the PR (or the "no suggestions" log), tune the deny list based on what you see, run again.

Reviewing scan PRs

Scan PRs have a slightly different rhythm from error-driven PRs. An error-driven PR has a specific failure mode it's responding to, so the review question is "does this fix the observed failure?" A scan PR is more open — the "failure" is hypothetical. The review question becomes "is this worth merging as an improvement?"

Most scan PRs we see fall cleanly into three buckets: obvious improvements (missing await, unhandled promise rejection), genuine-but-debatable improvements (a more defensive null guard on a code path that was probably fine), and false positives. Merge the first, discuss the second, close the third. Over time the second bucket shrinks as your deny list and prompt-level context improve.

Suppressing noisy categories

If the scan keeps suggesting the same unwanted class of fix — say, adding TypeScript narrowing to deliberately loose any calls — the right response is to tighten the deny list to exclude the relevant files. The scan's prompt is already strict about what counts; further hand-tuning of the prompt itself isn't exposed today.

The activity log shows which files produced which suggestions, so tracing a noisy pattern back to its source is usually a one-minute exercise.

Interaction with runtime monitoring

Scans and runtime monitoring don't step on each other. A bug that fires in production goes through the runtime path and produces an error-driven PR; the next scan is free to touch the same file but will usually not suggest the same fix because the bug is no longer visible in the source. Occasionally a scan surfaces a second-order issue adjacent to a recently-fixed bug, which is useful — the area has known fragility and a proactive look is timely.

When to turn scans off

Scans stay valuable indefinitely, but they can become low-yield if a repo enters a maintenance phase with little active development. If that's the case, drop the frequency from weekly to monthly, or turn it off until the next feature cycle. Scans are opt-in per app, so you can keep monitoring on and scans off cleanly.