Error Classes
The error-classes card on the board shows script errors counted by page group during the selected range. Each row is a path group paired with an error class label, ranked by how many errors were counted. Errors appear only when the errors-on setting is enabled for the domain.
What an error class is
When a JavaScript error is thrown on a page that has the StatelessID script, the script can capture the error and send it as an event beacon of type e alongside the normal page view beacon. The error is classified by type and page group and stored as an aggregate count — the full error message, stack trace, and any user data are never stored.
The error class label on the board is derived from the error's type and a short normalised fragment of the message. Two different errors that share the same type and a similar message prefix may be folded into the same class. This prevents a script that throws thousands of unique error messages from flooding the error table with rows.
Error events count against your monthly quota the same way page view events do. If your site is throwing a large number of JavaScript errors, that error volume consumes quota. The errors-off toggle in Filters lets you disable error collection entirely if you want to preserve your quota for page views only.
How to read the error-classes card
The error-classes card appears below the four-card strip only when the selected range contains at least one counted error. The card header shows the total error count for the range. Each row shows the page group where the errors occurred and the error count for that group, ranked highest to lowest.
A page group with a high error count relative to its page view count is a page with a poor script quality ratio. For example, if /checkout has 200 page views and 180 errors, nearly every checkout page load is throwing a JavaScript error — a serious issue that should be investigated immediately.
The error-classes card in the main board view shows up to four rows. The full list is in the collapsible drawer's error-classes section, which shows up to eight rows. The CSV export includes all error-class rows above the privacy floor.
Errors and the fix list
When a page group has a non-zero error count in the selected range, it also appears in the fix list in the collapsible drawer. The fix list is an automatically generated attention list that surfaces page groups with errors or slow load speeds, linking each entry to the relevant help article. A page group appearing in the fix list does not mean the issue is severe — it means the board has evidence that something worth checking is happening on that page.
The fix list link next to an error-class entry points to this article. Read the error count in context with the page view count for that group. An error count equal to or larger than the page view count means the error fires on effectively every load. An error count much smaller than the page view count means the error occurs intermittently.
Enabling and disabling error collection
Error collection is controlled by the errors-off toggle in the Filters section of your dashboard. When errors are off, the script does not send error events and the error-classes card never appears. When errors are on, every unhandled JavaScript error on pages with the script has a chance of being sent as an e beacon.
Turning errors off does not delete historical error data. Previous error events in the database remain and will appear in ranges that predate the toggle change. The toggle only affects whether new error events are sent from the browser.
If you are on a site with noisy third-party scripts that throw many errors you cannot fix, turning errors off is a reasonable way to keep your error card clean and preserve quota for page view data. You can always turn errors back on later if you need to diagnose a new problem.
What error data does not contain
Error events are aggregates. The stored data contains the path group, the error class label, the day, and the count. No stack trace is stored. No variable values from the error are stored. No user identifier is stored. The error-classes card cannot tell you which specific line of code threw the error or what value a variable held when it happened.
For full error debugging, use a browser developer tools session or a dedicated error-tracking service. StatelessID's error classes are designed to tell you that a problem exists on a specific page group and approximately how often it occurs — not to replace a full error monitoring stack.
Troubleshooting
If the error-classes card never appears even though you know your site has JavaScript errors, confirm that errors are enabled in your Filters settings. The errors-off toggle disables error collection entirely. Also confirm that the errors are unhandled — errors caught by a try/catch block and not re-thrown are not captured by the script.
If an error class you saw yesterday is not visible today, confirm the selected date range includes yesterday. The error-classes card only appears when the selected range contains counted errors. Switching to a range that predates the error occurrence will make the card disappear.