Open an error feed on a fresh landing page and you will see something like 14 distinct errors in the first week. Maybe two of them are yours. The rest come from a visitor's translation extension, an ad blocker, a Facebook in-app browser, and a chat script you pasted in months ago.
If you treat all 14 as bugs you will burn a weekend and fix nothing that moves signups. The skill is sorting the feed in under 10 minutes.
Ignore errors that originate outside your page: extension URLs, cross-origin "Script error.", ResizeObserver notices, and failed ad or tracker scripts. Fix the two types that break signups: errors on the page with your form, and errors that fire right after a button click. Sort by count, then check each error's source and page URL.
What you can see for each error
Each captured error in OperatorStack carries a message, a source file, a line number, a stack trace (truncated to 2,000 characters), the page URL, and device info. It is also tagged error_source: site or error_source: operatorstack, depending on whether the source contains os.js or operatorstack.
Two details matter for sorting. The fingerprint is a hash of message|source|line, so the same error from the same file and line is one row with a count, not 200 rows. And promise rejections are captured with an empty source and line 0, so every rejection with the same message groups into one row even if it came from different code.
Errors to ignore
Mark these ignored in the Errors tab. They stay in your history and out of your active count.
1. Extension errors
The source starts with chrome-extension://, moz-extension://, or safari-extension://. A visitor's password manager or translator injected a script and it crashed. Your page is fine.
2. Cross-origin "Script error."
message: Script error.
source: (empty)
line: 0
Browsers hide the details of errors thrown by scripts loaded from another origin unless that script is served with CORS headers and loaded with crossorigin="anonymous". You get the two words and nothing else.
Do a manual test of your signup flow. If it works and the count is low, ignore it. If the count jumped the day you added a new third-party script, that script is the cause, and you can confirm by removing it on a staging copy.
3. ResizeObserver notices
ResizeObserver loop completed with undelivered notifications.
ResizeObserver loop limit exceeded
Both are the same harmless condition worded differently by Chrome and Safari. Nothing is broken for the visitor. Ignore both fingerprints.
4. Blocked ad and tracker scripts
Errors such as fbq is not defined or gtag is not a function mean an ad blocker removed a script and your own code called it anyway. The fix is a typeof fbq === "function" guard, but it affects tracking, not signups. Ignore it first, guard it when you have time.
Do not ignore an error because it looks unfamiliar. Ignore it because you have checked its source and page URL. "I do not recognize it" describes every error from code you did not write, including your payment or form script.
The two errors to fix first
1. Any error on the page that holds your signup form
Filter the list by the page URL of your waitlist or form page. A TypeError: Cannot read properties of null on that page, with error_source: site, deserves attention even at a count of 3. Three visitors who could not sign up is 3 out of maybe 60 who tried.
2. Errors that arrive right after a click
If an error appears on the first-seen timestamp of a visitor session that also shows a button click, the click handler failed. Browser-specific failures are the usual suspect: a newer JavaScript feature that one older Safari or in-app browser version lacks, while your code runs fine in your own Chrome.
Reproduce it with the device info shown on the error. Open the page in that browser, or in a Safari window or BrowserStack, and run the signup.
A 10-minute triage pass
Sort by count. The top rows are your noise or your biggest bug. Both matter.
Read the source of each top row. Extension URL, empty, or a third-party domain: ignore candidates. Your own domain or /assets/ path: keep.
Check the page URL. Anything on the page with your form stays active until you have reproduced it.
Mark ignored, then test one signup by hand. Submit the form yourself with your email. If it works on desktop and mobile, you are done for the week.
Re-check the feed after every deploy. A fix you ship moves a fingerprint to fixed. If the same fingerprint reappears, OperatorStack marks it regressed, which is your signal that the deploy brought it back.
What there is no setting for
OperatorStack does not have a rule engine that drops errors by message pattern before they are stored. You triage them in the dashboard. Client-side limits still apply: repeats of the same fingerprint inside 5 seconds are dropped, and capture is capped at 50 errors per rolling 60 seconds. For a pre-launch site, that is enough to keep a noisy extension from flooding your quota.
Frequently Asked Questions
Is it safe to ignore the 'Script error.' message?
Usually yes, but check the page first. The browser hides the message, file, and line number of errors from cross-origin scripts, so you cannot tell whose code failed. If the count is low and your signup flow works in a manual test, mark it ignored. If it spikes right after you add a new third-party script, that script is the cause.
Why do I see errors from chrome-extension:// URLs?
A visitor's browser extension injected code into your page and that code threw. Password managers, translators, and ad blockers do this constantly. You cannot fix it from your side, so mark the fingerprint ignored.
What does 'ResizeObserver loop completed with undelivered notifications' mean?
A resize callback changed layout while the browser was still delivering resize notifications. Browsers report it as an error event but nothing breaks for the visitor. It is safe to ignore unless you can see a visible layout flicker.
What if ignoring an error hides a real bug later?
In OperatorStack, an ignored error keeps its history. If the same fingerprint appears again after you marked it fixed, it is flagged regressed. Ignoring is not deleting, so the count keeps accumulating and you can reopen it.