Errors Off
The JavaScript error signal is on by default. A single attribute on the script tag disables it. With errors off, window.onerror is never touched and no error beacon is ever sent from that page.
What the error signal does by default
When asset.js loads on a page, it registers a listener on window.onerror by default. If an uncaught JavaScript error fires on that page — from your code, from a third-party script, or from anything else running in the same page context — the listener catches it and sends a lightweight companion beacon. That beacon carries exactly one field: the page path where the error occurred. No error message, no stack trace, no variable values, no error type.
The dashboard shows a count of how many page loads produced at least one uncaught error on each path. The count represents page loads, not individual errors. If three uncaught errors fire during a single page load, the counter increments once. The signal tells you how common the error condition is across visitors, not how many total errors fired.
The error signal uses a small portion of the same beacon infrastructure as the page view count. It is not a full error monitoring system. It does not capture enough detail to debug a specific error. What it tells you is which pages have a reproducible problem and roughly how often it affects visitors. That is a useful triage signal even without the detail.
How to turn errors off
Add the data-no-errors attribute to your asset.js script tag. The full tag with the attribute looks like this: <script src="https://statelessid.com/asset.js" data-k="YOUR_KEY" data-no-errors defer></script>. With data-no-errors present, the script checks for the attribute before doing anything with window.onerror. If the attribute is found, the error hook is never registered. The script processes the page view beacon normally and exits without touching the error listener.
The attribute is a boolean flag — it does not take a value. Its presence means errors are off; its absence means errors are on. You can add it to some pages and leave it off on others if you want error tracking on most of your site but not on a specific page or section.
If your site uses a shared template to inject the script tag, adding data-no-errors to the template disables error tracking across every page the template renders. If you want errors off everywhere, that is the most efficient change. If you want errors off only on certain pages, add the attribute in the template conditionally or in the specific page files that need it.
When disabling error tracking makes sense
If you already have a dedicated JavaScript error monitoring tool — one that captures error messages, stack traces, and affected browsers in detail — the StatelessID error signal adds limited value on top of that. You are already getting richer information from the dedicated tool. Running both means two error beacons leave the page on each uncaught error, which is redundant overhead. Disabling the StatelessID error signal removes the duplication.
Some organizations have data governance requirements that restrict which third parties can receive any information about page behavior, even at the aggregate level. If error monitoring traffic must flow only through approved channels and StatelessID is not on the approved list for that signal type, disabling the error beacon keeps the traffic pattern clean.
If your site is a single-page application with frequent expected exceptions from third-party libraries, or if you are working through a period of heavy development where errors are expected and you are tracking them through developer tooling, disabling the signal temporarily prevents your dashboard from showing an Errors count that does not reflect the user experience of a stable release.
What changes and what stays the same
With data-no-errors present, the Errors column in your dashboard will show zero for any page load from that site. No error beacon is sent regardless of how many uncaught exceptions fire on the page. The window.onerror property is not modified by the script — if your own code or another script sets a window.onerror handler, it is unaffected.
The main page view count is completely unaffected. The referrer data, the screen class data, the load speed band, and every other field collected in the standard beacon continue to work normally. The only thing that changes is the error count. Removing error tracking does not change the number of page views recorded, the sources shown in the referrer section, or the device breakdown.
If you later decide you want error tracking back, remove the data-no-errors attribute from the script tag. The error hook activates again on the next page load. There is no backfill — errors that occurred while the attribute was present are not recovered — but counts resume from the moment the attribute is removed from the live page.
Troubleshooting
If you added data-no-errors to the script tag but the Errors section of your dashboard still shows counts, the most likely cause is a caching layer. If your server, CDN, or hosting platform caches the HTML of your pages, the cached version may still have the old script tag without the attribute. Purge the page cache after making the change and reload the dashboard after a fresh visit to see the effect.
If you removed data-no-errors to re-enable error tracking and the Errors count remains at zero even after several page loads, verify that the live page actually received the updated tag by checking the page source in a browser. Then test that the error hook is active by opening browser developer tools on the page and running a command that throws an uncaught error — for example, typing undefined_variable.property in the console and pressing enter. If that produces an entry in the Errors section within a minute, the signal is working correctly.
If the Errors count is unexpectedly high for a page that you do not believe has JavaScript problems, the errors may be originating from third-party scripts loaded on the same page. The window.onerror handler catches uncaught errors from all scripts in the page context, not only your own code. Identifying the source requires opening developer tools and looking at the error console while the page loads to see which script is throwing.