SID Script

sid-script appears in the Errors section of your dashboard when asset.js detected an uncaught JavaScript error during a page load. The number shown is not how many individual errors occurred — it is how many page loads had at least one uncaught error.

What generates a sid-script signal

asset.js listens for uncaught JavaScript errors through the window.onerror event handler. When any JavaScript on the page throws an error that is not caught by a try-catch block and not suppressed by the script that threw it, the onerror handler fires. At that point, asset.js sends a companion signal to the server that records the page path where the error occurred.

The signal is capped at one per page load. If ten uncaught errors fire on the same page load — from different scripts, at different times during the load — only the first one triggers the signal. The page path is recorded once. The count in your Errors section reflects how many page loads produced at least one uncaught error, not how many total errors were thrown.

The signal fires regardless of which script caused the error. window.onerror intercepts uncaught errors from all JavaScript on the page: your own code, third-party scripts, browser extensions that inject scripts into the page, and any dynamic code loaded by any of those. The path recorded is the page where the error occurred, not the script that caused it.

What the signal contains

The sid-script signal contains exactly one field: the page path where the error occurred. No error message is included. No stack trace. No variable values at the time of the error. No information about which script threw the error. No line number, no column, no error type. Only the path is sent.

This design keeps the error signal within the same data minimization principles as the visit beacon. An error message or stack trace can contain user-generated content, internal application state, or other sensitive values that would be inappropriate to send to a third-party server. The path tells you where errors are occurring. Diagnosing what the errors are is done locally with developer tools, not through the dashboard.

The Errors section in the dashboard shows a count per path for the selected period. A path with a high count had many page loads where at least one uncaught error fired. A path with a count of one had exactly one such page load during the period. The absence of a path from the Errors section means no page load on that path triggered an uncaught error that made it through to the onerror handler.

How to diagnose the error

Open the page in question in your browser with the developer tools Console tab visible. Reload the page. Uncaught errors appear in the console in red. The error message, the script filename, the line number, and often a partial stack trace are visible there. This is the information you need to diagnose and fix the error — information that intentionally never appears in the StatelessID dashboard.

If the error is intermittent and does not reproduce on every load, it may depend on a specific browser state, a specific screen size, a specific load order, or a race condition between asynchronously loaded scripts. Try multiple browsers, clear the cache, disable extensions, and load the page on a slow network connection to surface errors that do not appear in optimized development conditions.

If the console does not show the error but the Errors section still shows a count for that path, the error may have been caught and re-thrown in a way that reaches onerror without appearing prominently in the console, or it may have been thrown by a third-party script that suppresses its own console output. In that case, set a breakpoint on the onerror handler itself in the debugger to inspect the next error event when it fires.

Third-party script errors

Because window.onerror catches errors from all scripts on the page, a non-zero Errors count for a path does not necessarily mean your own code has a bug. Third-party scripts — ad networks, chat widgets, social embeds, analytics libraries, A/B testing tools — can throw uncaught errors that are entirely outside your control. These count toward the sid-script signal the same as errors from your own code.

A high error count on a page that has several third-party scripts is worth investigating by temporarily removing those scripts one at a time and checking whether the error count decreases. If removing a specific third-party script eliminates the errors, that script is the source. Updating it to a newer version, replacing it with an alternative, or removing it if it is not essential resolves the error without changes to your own code.

Troubleshooting

If the Errors section shows a high count for a path but you cannot reproduce the error in development, the error may be environment-specific. Check whether it appears on production but not locally, on mobile browsers but not desktop, or on a specific OS. Use browser stack reports or a separate error-monitoring tool if you need detailed error data across your real user base — the sid-script signal tells you which pages are affected, not the details needed to reproduce and fix the error.

If the Errors section is populated for every page path on your site, the error may be in a shared script included on all pages — a global utility, your main bundle, or a third-party script loaded site-wide. Open any two affected pages in the console and look for a common error that appears on both. A shared source produces a consistent error message across all pages.

If you recently deployed a code change and the Errors count jumped afterward, the change introduced a regression. Compare the deploy timestamp to the first appearance of the errors in the timeline. Roll back or fix the specific change that introduced the error. The path data in the Errors section can tell you which pages are affected, which narrows the search to the code paths those pages execute.