> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Front-end errors in AppSignal

> How front-end errors are grouped into issues, and what the Errors view shows you.

<Note>
  Browser monitoring is a beta [AppSignal Labs](/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](https://discord.gg/EjF6ykYx63).
</Note>

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.

<h2 id="how-errors-are-grouped">
  How errors are grouped
</h2>

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()`](/browser/installation#report-the-current-route), 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.

<h2 id="reading-the-issue-list">
  Reading the issue list
</h2>

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.

<h2 id="filtering-by-time-and-version">
  Filtering by time and version
</h2>

* **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.

<h2 id="investigating-an-issue">
  Investigating an issue
</h2>

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](/browser/error-tracking#sourcemaps) for the version set in `appVersion`.
3. **Read the [breadcrumbs](/browser/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()`](/browser/error-tracking#tags) 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](/browser/distributed-tracing#before-you-start), 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.

<h2 id="triage-and-notifications">
  Triage and notifications
</h2>

You can assign, mute, and change the state of these issues. They also support notification settings. Read more in [errors](/errors). Because front-end errors live in the `browser` [namespace](/guides/namespaces), 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](/browser/migration).

<h2 id="errors-you-will-not-find-here">
  Errors you will not find here
</h2>

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](/browser/error-tracking#errors-that-are-not-reported). If an error you expected is missing, work through [troubleshooting](/browser/troubleshooting#an-error-is-missing).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.