Front-end errors in AppSignal

The Errors view lists the errors your front end reported, grouped into issues. It is the same issue model your back-end errors use, so anything you already do with an exception from Ruby or Node.js works here too.

​

How errors are grouped

Occurrences of the same error type on the same route become one issue. A bug that fires ten thousand times is one thing to triage rather than ten thousand notifications. The route is what the SDK reported through setRouteTemplate(), or the page’s path when nothing was declared. This is why declaring templates matters: without them, /orders/1 and /orders/2 are different routes, and one bug fragments into an issue per order.

​

Reading the issue list

Each issue in the list carries:

• The error class and message, with the route it happened on.
• The version it was introduced in, which is often the fastest way to spot a regression: a new issue against your most recent release is a release you may want to look at.
• A trend for the selected period, so a spike reads differently from a steady trickle.
• The total number of occurrences in the period.
• When it was last seen.
• Who it is assigned to.

You can sort by the most recent occurrence or by volume, depending on whether you are triaging what just broke or what breaks most.

​

Filtering by time and version

• Time range. Presets from one hour to 30 days, or a custom range.
• Version. Restrict the list to the errors reported by a single release. Combined with the introduced-in column, this is how you confirm whether a deploy is responsible.

​

Investigating an issue

Opening an issue shows one sample of the error: when it happened, the page it happened on, and the deploy it first appeared in, along with four things you debug from.

• The error message, in full. This is where the meaning is. TypeError tells you almost nothing on its own, while Failed to fetch dynamically imported module tells you a lazily loaded chunk never arrived.
• The tags you set with setTags(), shown alongside the user agent and the revision, if you have set appVersion. A few tag names do more than filter. Tag with country_code or browser and you get attribute distributions, which show you which countries or browsers see the most errors. Link templates turn a tag into a link, so a user_id tag can open that user in your own admin.
• The backtrace, which you can read in full or narrowed to your own application. Front-end stacks are often almost entirely framework frames. A removeChild failure from React arrives as a wall of react-dom frames with nothing of yours in sight, and the application view is what cuts through it.
• The breadcrumb timeline leading up to the error, which is usually the part that saves you.

Each breadcrumb carries its own detail. A network entry shows the method, the URL, the response status, and how long the request took. A click entry shows which element the user selected. A long task entry names the script that blocked the main thread, and for how long. A trail that runs from a click, through a GraphQL request that took nearly three seconds, to the error itself is often the whole explanation, without reproducing anything. Backtraces from a minified bundle are resolved through sourcemaps, matched on the app version. Without a version set, backtraces stay minified. A sample can be exported as JSON or Markdown, which is the quickest way to attach one to a ticket or hand it to an assistant. Each issue also has a logbook, where you and your team leave notes in Markdown recording what you found.

​

Triage and notifications

Issues can be assigned, given a state, muted, and configured with their own notification settings, and the rest of AppSignal’s incident tooling works on them too. Read more in errors. Because front-end errors live in the browser namespace, those settings are separate from your back-end ones. If you are migrating from @appsignal/javascript, note that its errors were reported to frontend, so the notification settings you configured there do not carry over. Read more in the migration guide.

​

Errors you will not find here

Some errors never reach the SDK at all, including those thrown before it initializes, those from cross-origin scripts served without CORS headers, and those inside iframes. Each has a workaround, listed in errors that are not reported. If an error you expected is missing, work through troubleshooting.