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.
Browser monitoring reports front-end errors with recent breadcrumbs and web vitals from real users. Your back-end telemetry cannot answer questions like these:
  • After a deploy, some users hit Failed to fetch dynamically imported module while your own testing stays clean. Which release introduced it, and what was the user doing when it happened?
  • Your traces show the server responding in 80 ms, but users still say the dashboard feels slow. Is the time going somewhere in the browser?
  • You shipped a change to your JavaScript bundle yesterday. Did the pages your users spend the most time on get slower?
Browser monitoring is its own section of your application in AppSignal, with two views:
  • Errors groups front-end errors into issues you can triage, assign, and get notified about.
  • Performance reports web vitals per route, so you can compare releases and find the pages that need work.

​
What the SDK collects

Browser monitoring is fed by AppSignal for Browser, the @appsignal/browser package you add to your front end. It collects three things once initialized, with no further setup:
  • Errors include uncaught JavaScript errors and unhandled promise rejections. Reports carry a stack trace when available and any tags you set.
  • Breadcrumbs show recent navigation, clicks, network requests, and console warnings and errors before an error.
  • Web vitals are five measurements of how the page feels to use. How long it takes to load, how quickly it responds, and whether the layout jumps around while loading.
The SDK docs cover how to install and configure it, and exactly what each of those carries. This section covers what AppSignal does with it.

​
How it relates to your back-end errors

Front-end errors go to the browser namespace. This keeps them separate from back-end error lists and notification settings. The Browser section gives you a dedicated view of front-end errors and performance. These are regular AppSignal issues. You can group, triage, and notify on them. Web vitals are separate from your back-end performance and tracing data. A browser measures how long a page took to become usable. A trace measures what your server did. When the same route is slow in both, you are looking at one problem from two sides.

​
Two settings worth getting right

These two choices decide how useful the data is:
  • Report the route template. Pass /orders/:id rather than /orders/1042. Errors use the raw path when you do not set a template, which can split one bug into many issues. The processor derives an approximate template for web vitals, but your router’s pattern is more reliable. Read more in reporting the current route.
  • Set an app version. Both views can filter by the version that reported the data. That is how you tell whether a release made things worse. Read more in appVersion.
For the full list of what is recorded, and how to turn categories off, read the breadcrumbs page.