> ## 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. 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). 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()`](/browser/installation#report-the-current-route), 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()`](/browser/error-tracking#tags), shown alongside the user agent and the revision, if you have set [`appVersion`](/browser/configuration#appversion). A few tag names do more than filter. Tag with `country_code` or `browser` and you get [attribute distributions](/guides/tagging/attribute-distributions), which show you which countries or browsers see the most errors. [Link templates](/application/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](/browser/breadcrumbs)** 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](/browser/error-tracking#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](/errors). Because front-end errors live in the `browser` [namespace](/guides/namespaces), 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](/browser/migration). ## 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](/browser/error-tracking#errors-that-are-not-reported). If an error you expected is missing, work through [troubleshooting](/browser/troubleshooting#an-error-is-missing).