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 what happens in your users’ browsers: front-end errors, each with the trail of events that led up to it, and web vitals measured on real page loads. 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 are the JavaScript errors your code throws without catching them, including promises that fail. Each one arrives with a stack trace and any tags you set.
  • Breadcrumbs are a timeline of what happened before an error: the pages the user opened, what they selected, the requests the page made, and what the console logged.
  • 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 are reported to the browser namespace, which keeps them out of your back-end error lists and their notification settings. This is the reason browser monitoring is a section of its own rather than a filter on your existing errors: a front-end developer opens a view that contains front-end work and nothing else, instead of narrowing a view built for server-side debugging. They are otherwise ordinary issues: the grouping, triage, and notification model is the same one errors uses everywhere else in AppSignal. 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. Tell AppSignal the user is on /orders/:id, not /orders/1042. Errors and web vitals are both grouped by whatever route you report. Without a template, a thousand orders become a thousand separate routes, and one bug becomes a thousand issues. 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.