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

Select an issue in the list to open it in a side panel. The panel has two tabs:

• Sample: one time the error happened in a user’s browser.
• Logbook: your team’s notes on the issue, with its state changes and linked GitHub issues.

The Sample tab shows:

• Error message and Tags.
• The backtrace, for errors your code throws.
• Trace service map and Trace timeline.
• Related log lines, when the back end is instrumented.
• Breadcrumbs.

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 errors your code throws. 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 backtrace. The Sample tab shows its trace instead. The Trace service map and Trace timeline cards show its browser span. If the back end is instrumented, its spans appear there too, followed by its related log lines. Open full trace page, the icon next to the issue number, opens 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.