Skip to main content
Browser monitoring is a beta AppSignal Labs feature. The @appsignal/browser package is published under the beta tag on npm, and its configuration and API may still change between beta releases. Share feedback in our Discord community.
Once init() has run, AppSignal for Browser reports uncaught errors on its own. There is nothing to wrap and no handler to register. It listens for two things on the page’s main window:
  • Errors your code throws and never catches, through the error event.
  • Promises that fail with nothing to handle the failure, through the unhandledrejection event.
The SDK starts sending each error when it is caught, without waiting for a web-vitals batch. Delivery still depends on the browser and network.

What is reported

  • Error name and message. The kind of error, for example TypeError, and the message it came with.
  • Backtrace. The stack trace, one line per frame. Empty if the browser gives none.
  • Action. The route the error happened on. Errors are grouped by this.
  • Revision. The appVersion you set. Used to filter by version and to find the right sourcemaps.
  • Tags. Whatever you set with setTags().
  • Service name. The serviceName you set, or Browser. It labels the front end among the services of a trace.
  • Breadcrumbs. Up to 25 recent breadcrumbs that help explain the error.
  • URL and user agent. The page the error happened on, with query parameters removed as set by your allowlist, and the browser’s user agent.
A rejected promise can contain a value other than an Error. The SDK turns that value into an error message when it can. Errors are reported to the browser namespace, which keeps them separate from your back-end errors and their notification settings.

How errors are grouped

Errors group by action. This is the template set with setRouteTemplate(), or the raw page path when none was set. Declaring a template is what stops an ID-heavy route from fragmenting into one error group per ID:
Call it on each router navigation. It is the same value web vitals are attributed to, so one call covers both.

Reporting errors manually

Use captureError() for errors you catch yourself. It goes through the same pipeline as an uncaught error, including breadcrumbs, tags, sampling, and beforeError:
The current SDK accepts a second context argument, but does not include it in ordinary error reports. Use setTags() for values that should appear on subsequent errors. React applications can catch render errors with the error boundary instead of wrapping components by hand.

Failed requests

With tracePropagationTargets set, a request to your API that answers 5xx or times out is reported on its own. It arrives as an HTTPError or a TimeoutError, carrying the trace ID the request sent to the back end. If the back end continued the trace, its spans appear beneath the browser error in the trace timeline. Read more in distributed tracing for Browser.

Tags

Tags are string key-values attached to every error reported from that point on. They are what you filter and search errors by in AppSignal:
Each call adds to the tags you already set rather than replacing them. Values become text. An empty value removes its tag. You can keep up to 32 tags; the oldest is dropped when needed. Long values are shortened to 256 bytes when they arrive. Read more in our tagging guide. A few tag names do more than filter. The country_code, country, and browser tags produce attribute distributions. You can turn any tag into a link with link templates.

Rate limits

A page stuck in a loop can throw thousands of errors a second. Two limits stop the SDK from becoming the problem it is meant to report:
  • The same error over and over. The message and first stack line determine whether two errors are repeats. AppSignal reports it at most five times every 10 seconds.
  • Too many errors at once. No more than 100 errors are reported every 10 seconds in total. This catches a page throwing many different errors, which the first limit would miss.
If errors go missing while a page is misbehaving, one of these two is why. To send fewer errors on purpose instead, set errors.sampleRate.

Sourcemaps

A minified bundle produces stack traces full of one-letter names and enormous line numbers. Sourcemaps turn those back into the file names, functions, and line numbers you wrote. Each error sends appVersion as its revision. AppSignal uses it to find the sourcemaps for that build. Without it, stack traces stay minified. If your sourcemaps are public, sitting next to your JavaScript files, there is nothing more to do. If you would rather not publish them, upload them to the sourcemaps API endpoint using the same revision.

Errors that are not reported

Some errors never reach the SDK. Most of these are browser restrictions rather than AppSignal limitations, and each has a workaround.
Errors from scripts on another domain. When a script loaded from somewhere else throws, the browser refuses to share the details. All your page sees is the message Script error., with no stack trace and no line number. The SDK drops these opaque errors because they contain no useful detail. To capture CDN script errors, send an Access-Control-Allow-Origin header from the CDN. Add crossorigin="anonymous" to the script tags. Errors inside iframes. The SDK listens only on the window where it runs. To monitor an iframe you control, initialize the SDK inside that frame too. The parent page cannot capture errors from a cross-origin iframe. Errors before init(). Anything that throws before init() runs is missed. Import your AppSignal setup first, ahead of other libraries and your own code.

Filtering out browser noise

Some errors come from the browser or its extensions, not from your code, and you cannot fix them. The install flow’s Error filtering option drops them with beforeError:
Each pattern is checked against the error’s message, stack trace, and file name:
  • ResizeObserver loop: a browser notice that resize notifications were deferred to the next frame. It is usually harmless.
  • Script error.: an error from a script on another domain, with no detail to debug. The SDK already drops those that arrive without a stack trace.
  • -extension://: an error from a browser extension, such as a chrome-extension:// or moz-extension:// script.
  • webkit-masked-url: the address Safari shows in place of an extension’s script.
Add a pattern to IGNORED for any other error you have decided to ignore. A dropped error leaves no breadcrumb and is not counted as a repeat. It does count towards the limit of 100 errors every 10 seconds. Read more in filtering errors and breadcrumbs.

Reviewing errors in AppSignal

The Errors view groups these into issues you can filter by version and time range, assign, and get notified about. Read more in front-end errors in AppSignal.