Javascript Errors

Statalog automatically captures JavaScript errors that occur on your pages and groups them into a structured error report. This gives you visibility into the technical failures your visitors encounter — without requiring a separate error monitoring service for basic coverage.

What is captured

The Statalog tracker listens for two types of JavaScript failure:

Uncaught exceptions — Errors that are thrown by JavaScript code and not caught by any error handler. These are captured via the window.onerror event listener, which fires whenever an unhandled exception propagates to the top of the call stack. This includes syntax errors, reference errors, type errors, and any other runtime exception that is not caught by a try/catch block.

Unhandled Promise rejections — Errors that occur inside Promises and are not handled by a .catch() handler or try/catch in an async function. These are captured via the unhandledrejection event. In modern web applications that make heavy use of async code and API calls, unhandled rejections are a common source of silent failures that would otherwise go unnoticed.

Error fingerprinting and grouping

Rather than showing you every individual error occurrence as a separate entry (which would produce thousands of rows for a single recurring error), Statalog groups errors by their fingerprint.

A fingerprint is computed from three fields:

  1. Error message — the text of the error (e.g. TypeError: Cannot read properties of undefined (reading 'price'))
  2. Source file — the URL of the JavaScript file where the error occurred (e.g. https://yoursite.com/js/checkout.js)
  3. Line number — the line in the source file where the error was thrown (e.g. 142)

Errors with identical message + source + line are grouped as a single error entry with an occurrence count. This means instead of 3,000 individual rows, you see a single entry: TypeError: Cannot read properties of undefined (reading 'price') at checkout.js:142 — 3,000 occurrences.

This grouping makes the report immediately actionable: the errors at the top of the list (by occurrence count) are the ones affecting the most visitors and deserve the most attention.

What the error report shows

For each error group, the report displays:

Error message The full error message text. This is usually enough to understand the nature of the failure without needing to look at code.

Source file and line number The file where the error originated and the line number. In production environments with minified code, the line number will refer to the minified bundle rather than the original source. Source maps (if configured) would be needed to map this back to original source, but even without source maps, the file name and approximate line number are useful for narrowing down the location.

Occurrence count How many times this error was recorded in the selected date range. This is the primary metric for prioritising fixes — high occurrence count means the error is affecting many visitors frequently.

Affected visitors The number of unique visitors who encountered this error at least once. An error that affects 1,000 visitors once each is very different from one that affects 10 visitors 100 times each — both would have the same occurrence count, but the affected visitor count distinguishes them.

Browser and OS breakdown Which browsers and operating systems are reporting this error. Some errors are browser-specific — a JavaScript API that is not supported in a particular browser, or a rendering quirk that triggers different code paths. The browser breakdown tells you whether an error is universal or isolated to a specific environment.

First seen / Last seen When the error was first recorded and most recently recorded in your data. An error that was first seen today is likely a regression from a recent deployment. An error that has been present for six months is a long-standing issue.

Opting out of error tracking for a page

If you want to disable JavaScript error tracking for a specific page — for example, a page that embeds third-party content that generates expected errors you do not want to track — you can add the data-no-errors attribute to your Statalog script tag on that page:

<script
  src="https://cdn.statalog.com/tracker.js"
  data-site="YOUR_SITE_ID"
  data-no-errors
  async
></script>

This disables error capture on that specific page. All other tracking (pageviews, goals, performance timing) continues normally.

Use cases

Catching checkout failures Checkout flows are among the most JavaScript-heavy parts of most websites, and errors there directly cause lost revenue. An error at checkout.js:142 occurring 500 times a day is costing you conversions. The error report surfaces this immediately so you can investigate and fix it.

Detecting regressions after deployments Sort the error report by "First seen" to find errors that appeared recently. Correlating a spike in new errors with a specific deployment date is usually straightforward. This is the fastest way to identify whether a recent code change broke something for visitors.

Prioritising technical debt Long-standing errors that affect many visitors are often ignored because they were never made visible. The error report makes this technical debt explicit and quantified — "this error is affecting 800 visitors per week" is a concrete number that justifies engineering time.

Understanding browser-specific failures If an error is occurring only on Safari or only on a specific version of Chrome, the browser breakdown column will show this clearly. Browser-specific errors are often caused by API support differences and can be fixed with targeted feature detection or polyfills.

Privacy

The error report stores only technical metadata:

  • Error message text
  • Source file URL
  • Line number
  • Browser and OS (parsed from User-Agent, same as all other reports)
  • Timestamp and occurrence counts

No user data, no session content, no form field values, no personally identifiable information is captured or stored. Error messages themselves occasionally contain sensitive information if a developer has inadvertently included user data in error text — for example, Error: invalid email address: user@example.com. This is a code quality issue on the application side, not a Statalog behaviour, but it is worth reviewing error messages in your report if your application code constructs error messages dynamically from user input.

FAQ

Does JavaScript error tracking replace Sentry or similar tools? No. Statalog's error tracking is a lightweight complement to dedicated error monitoring platforms, not a replacement. Sentry and similar tools provide capabilities that Statalog does not: full stack traces, source map integration, release tracking, error alerting, performance tracing, and team workflow features like assignments and status management.

What Statalog provides is a low-friction baseline: error visibility built into the same analytics dashboard you already use, with no additional setup. For many small sites and early-stage products, this is sufficient to catch the errors that matter most. As your product matures and error volume grows, a dedicated error monitoring tool becomes the right addition — and the two run comfortably alongside each other.

Are errors from third-party scripts captured? Errors from cross-origin scripts (scripts loaded from a different domain than your page) are reported by the browser with a generic message: Script error. with no source file or line number. This is a browser security restriction (the Same-Origin Policy) that prevents detailed error information from leaking across origins. Statalog captures these Script error. entries but they provide limited diagnostic value. To get full error details from third-party scripts, those scripts would need to be served with a Access-Control-Allow-Origin header and loaded with the crossorigin attribute.

What if the same error has a slightly different message each time? Fingerprinting is based on exact message text, source file, and line number. If an error message is dynamically constructed and includes variable content (e.g. Error: failed to load product ID 12345 where the ID changes each time), each unique message will be a separate fingerprint. This can fragment what is actually one error type into many rows. The best practice is to keep error message text static and put dynamic values in structured data separate from the message string — but this requires fixing the application code rather than configuring Statalog.