Front-end errors in AppSignal

The Errors view lists the errors your front end reported, grouped into issues. It uses the same issue model as back-end errors. You can triage and assign them in the same way.

​

How errors are grouped

AppSignal groups related errors into issues using the reported route and your application’s grouping settings. Repeated occurrences can appear as one issue to triage. The route is what the SDK reported through setRouteTemplate(), or the page’s path when nothing was declared. Without a template, /orders/1 and /orders/2 are different error routes. One bug can become two issues.

​

Reading the issue list

Each issue in the list carries:

• The error class and message, with the route it happened on.
• The version where it was introduced. If it first appears in your latest release, check that deploy.
• 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.

Sort by recent occurrence to find new failures. Sort by volume to find frequent ones.

​

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

Open an issue to inspect a sample: one time the error happened in a user’s browser. The sample gives you the error message and what happened around it.

1. Read the message. It tells you what failed. For example, POST https://api.example.com/orders: HTTP 503 means the checkout API returned a server error.
2. Check the backtrace for JavaScript errors. It shows where the error happened in your code. If you see minified code instead of readable file names and lines, upload sourcemaps for the version set in appVersion.
3. Read the breadcrumbs. They show events before the error, such as a button selection or a network request. If the user selected Pay just before /orders took three seconds, check that API request first.
4. Check the version and tags. Compare the sample’s version with your recent deploys. Use tags set with setTags() to narrow down who was affected.

A failed API request reported as an HTTPError or TimeoutError has no JavaScript backtrace. On the full issue page, select Traces, then Fullscreen in the Trace timeline card to inspect its browser span. If the back end continued the trace, its spans appear there too. From the Browser Errors side panel, use Open full trace page to reach the full issue page. You can export a sample as JSON or Markdown to share it with your team. Use the issue’s logbook to record what you found.

​

Triage and notifications

You can assign, mute, and change the state of these issues. They also support notification settings. Read more in errors. Because front-end errors live in the browser namespace, those settings are separate from your back-end ones. If you migrate from @appsignal/javascript, set up notifications for browser. Settings for frontend do not carry over. Read more in the migration guide.

​

Errors you will not find here

Some errors never reach the SDK. Examples include errors before init() and errors inside uninstrumented iframes. Opaque cross-origin script errors are dropped. Each has a workaround, listed in errors that are not reported. If an error you expected is missing, work through troubleshooting.