Runtime error monitoring vs scheduled scans

nreactive ships two parallel surfaces that both end at the same place: an automatically generated pull request that fixes a bug. They start from very different places, though, and understanding the difference helps you decide how aggressively to lean on each.

Runtime monitoring: reactive by design

Runtime monitoring catches what users see. The browser or server SDK installs global handlers for uncaught exceptions, unhandled rejections, network failures, console errors, and CSP violations. Whenever one fires, a small event ships to the nreactive endpoint: the message, a normalized stack, the file and line where the error originated, severity, and a runtime context blob with breadcrumbs and request metadata.

That event is fingerprinted — a stable hash over the normalized message, error type, file, and top stack frames — and deduped against whatever is already in the database. A new fingerprint opens a record; an existing one bumps occurrences and updates daily counts. When a record transitions from "new" to "analyzing" the pipeline picks it up: fetch the referenced files from the repo, compress them, send them to the model with the stack and runtime context, and either generate a PR or open a ticket depending on confidence.

The shape of runtime monitoring is reactive. You see what production saw, and the pipeline responds.

Scheduled scans: proactive by design

Scheduled scans go the other way. Instead of waiting for an error to fire, the pipeline periodically reads your repository and asks the model: is there anything in this code that would fail given the wrong input? No runtime event has to happen for a scan to raise a PR.

The scan is stricter than runtime monitoring about what counts as a finding. Runtime errors are by definition real — something broke — so even a low-confidence fix can be worth a ticket. Scan suggestions are hypothetical until proven otherwise, so the prompt explicitly demands high confidence, verifiable from the provided source, and rules out stylistic nits or pure refactors. In practice that means scheduled scan PRs are rarer than runtime PRs but tend to carry a higher hit rate per suggestion.

Where they overlap and where they don't

Runtime monitoring will never catch a bug that production hasn't triggered yet. If your app has a rare code path that only fires on leap-year Thursdays, monitoring won't know about it. Scheduled scans close that gap for code visible to the model — but they only see what's in the repository. A bug whose cause is in a dependency, or in a live runtime configuration, is invisible to scans and only surfaces via monitoring.

So the two surfaces are complementary rather than competing. Most teams run both: monitoring on every app from day one, scans on an opt-in weekly cadence per app.

Cost and noise profiles

Runtime monitoring is cheap per event and noisy when an app misbehaves: one bug can fire thousands of times in an hour. Dedup and the transient suppression filter keep the dashboard readable, but the pipeline still has to process the first few occurrences of a new fingerprint. On the analyzer side, cost is bounded by the per-app daily fix limit.

Scheduled scans are predictable. A single run reads a bounded number of files, produces at most five suggestions, and costs a fixed amount of tokens. You can run them daily or weekly and the billing is essentially a line item.

Choosing a default setup

A sensible starting point: install the SDK in production, leave monitoring on. Wait a few days, watch the dashboard, and tune the deny list based on what you see. Then enable a weekly scheduled scan per app. If a team is comfortable with automated fixes, raise the auto-merge threshold on the obvious categories (null guards, missing awaits) and leave the rest as normal review.

Both paths converge on the same artefact: a PR that explains what was wrong and how the fix addresses it. The difference is just who noticed first — your users, or the scan.

One more contrast worth naming

Runtime monitoring sharpens your sense of what's breaking right now; scans sharpen your sense of what's fragile under plausible futures. Teams that lean only on monitoring end up feeling reactive — the backlog is whatever production decided to surface this week. Teams that lean only on scans end up with long hypothetical punch-lists and no feedback from reality. Together the two produce a steady-state dashboard that reflects both observed breakage and plausible breakage, and reviewers develop a good intuition about which channel they're reading at any given moment.