> ## 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-Fehler in AppSignal

> Wie Front-end-Fehler zu Issues gruppiert werden und was die Errors-Ansicht zeigt.

<Note>
  Browser monitoring ist ein Beta-Feature von [AppSignal Labs](/labs). Das Paket
  `@appsignal/browser` wird unter dem `beta`-Tag auf npm veröffentlicht, und
  seine Konfiguration und API können sich zwischen Beta-Releases noch ändern.
  Teilen Sie Ihr Feedback in unserer
  [Discord-Community](https://discord.gg/EjF6ykYx63).
</Note>

Die Errors-Ansicht listet die Fehler auf, die Ihr Front end gemeldet hat, gruppiert zu Issues. Es ist dasselbe Issue-Modell, das Ihre Back-end-Fehler verwenden, sodass alles, was Sie mit einer Exception aus Ruby oder Node.js bereits tun, auch hier funktioniert.

<h2 id="how-errors-are-grouped">
  Wie Fehler gruppiert werden
</h2>

Vorkommen desselben Fehlertyps auf derselben Route werden zu einem Issue. Ein Bug, der zehntausendmal auftritt, ist eine Sache zum Triagieren statt zehntausend Benachrichtigungen.

Die Route ist die, die das SDK über [`setRouteTemplate()`](/browser/installation#report-the-current-route) gemeldet hat, oder der Pfad der Seite, wenn nichts angegeben wurde. Deshalb ist das Angeben von Templates wichtig: Ohne sie sind `/orders/1` und `/orders/2` verschiedene Routen, und ein Bug zersplittert in ein Issue pro Bestellung.

<h2 id="reading-the-issue-list">
  Die Issue-Liste lesen
</h2>

Jedes Issue in der Liste enthält:

* Die Fehlerklasse und die Meldung, mit der Route, auf der der Fehler aufgetreten ist.
* Die Version, in der er **eingeführt** wurde, was oft der schnellste Weg ist, eine Regression zu erkennen: ein neues Issue gegen Ihr neuestes Release ist ein Release, das Sie sich ansehen sollten.
* Einen **Trend** für den gewählten Zeitraum, sodass sich eine Spitze anders liest als ein gleichmäßiges Tröpfeln.
* Die **Gesamtzahl** der Vorkommen im Zeitraum.
* Wann er **zuletzt** gesehen wurde.
* Wem er **zugewiesen** ist.

Sie können nach dem neuesten Vorkommen oder nach Volumen sortieren, je nachdem, ob Sie triagieren, was gerade kaputtgegangen ist, oder was am häufigsten kaputtgeht.

<h2 id="filtering-by-time-and-version">
  Nach Zeit und Version filtern
</h2>

* **Zeitraum.** Voreinstellungen von einer Stunde bis 30 Tage oder ein eigener Zeitraum.
* **Version.** Beschränken Sie die Liste auf die Fehler, die ein einzelnes Release gemeldet hat. Kombiniert mit der Spalte „Eingeführt in" bestätigen Sie damit, ob ein Deploy verantwortlich ist.

<h2 id="investigating-an-issue">
  Ein Issue untersuchen
</h2>

Wenn Sie ein Issue öffnen, sehen Sie ein sample des Fehlers: wann er aufgetreten ist, auf welcher Seite und in welchem Deploy er zuerst erschien, dazu vier Dinge, von denen aus Sie debuggen.

* **Die Fehlermeldung**, vollständig. Hier steckt die Bedeutung. `TypeError` sagt für sich genommen fast nichts, während `Failed to fetch dynamically imported module` Ihnen sagt, dass ein verzögert geladener Chunk nie angekommen ist.
* **Die Tags**, die Sie mit [`setTags()`](/browser/error-tracking#tags) gesetzt haben, angezeigt neben dem User Agent und der Revision, sofern Sie [`appVersion`](/browser/configuration#appversion) gesetzt haben. Einige Tag-Namen können mehr als filtern. Taggen Sie mit `country_code` oder `browser`, und Sie erhalten [Attributverteilungen](/guides/tagging/attribute-distributions), die zeigen, welche Länder oder Browser die meisten Fehler sehen. [Link-Templates](/application/link-templates) verwandeln ein Tag in einen Link, sodass ein `user_id`-Tag diesen Nutzer in Ihrem eigenen Admin öffnen kann.
* **Den Backtrace**, den Sie vollständig oder auf Ihre eigene Anwendung eingeschränkt lesen können. Front-end-Stacks bestehen oft fast ausschließlich aus Framework-Frames. Ein `removeChild`-Fehler aus React kommt als Wand von `react-dom`-Frames an, ohne dass etwas von Ihnen zu sehen ist, und die Anwendungsansicht schneidet genau das heraus.
* **Die [Breadcrumb-Zeitleiste](/browser/breadcrumbs)**, die zum Fehler geführt hat, und meist ist das der Teil, der Sie rettet.

Jeder Breadcrumb enthält eigene Details. Ein Netzwerkeintrag zeigt die Methode, die URL, den Response-Status und wie lange der Request gedauert hat. Ein Klick-Eintrag zeigt, welches Element der Nutzer ausgewählt hat. Ein Long-Task-Eintrag nennt das Skript, das den Main Thread blockiert hat, und für wie lange. Eine Spur, die von einer Auswahl über einen GraphQL-Request, der fast drei Sekunden gedauert hat, bis zum Fehler selbst läuft, ist oft die ganze Erklärung, ohne dass Sie etwas reproduzieren müssen.

Backtraces aus einem minifizierten Bundle werden über [sourcemaps](/browser/error-tracking#sourcemaps) aufgelöst, abgeglichen über die App-Version. Ohne gesetzte Version bleiben Backtraces minifiziert.

Ein sample lässt sich als JSON oder Markdown exportieren, was der schnellste Weg ist, es an ein Ticket zu hängen oder einem Assistenten zu übergeben. Jedes Issue hat außerdem ein Logbuch, in dem Sie und Ihr Team in Markdown notieren, was Sie herausgefunden haben.

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

Issues können zugewiesen, mit einem Status versehen, stummgeschaltet und mit eigenen Benachrichtigungseinstellungen konfiguriert werden, und der Rest von AppSignals Incident-Werkzeugen funktioniert ebenfalls damit. Mehr dazu unter [Errors](/errors). Weil Front-end-Fehler im `browser`-[namespace](/guides/namespaces) liegen, sind diese Einstellungen von Ihren Back-end-Einstellungen getrennt. Wenn Sie von `@appsignal/javascript` migrieren, beachten Sie: dessen Fehler wurden an `frontend` gemeldet, die dort konfigurierten Benachrichtigungseinstellungen werden also nicht übernommen. Mehr dazu im [Migrationsleitfaden](/browser/migration).

<h2 id="errors-you-will-not-find-here">
  Fehler, die Sie hier nicht finden
</h2>

Manche Fehler erreichen das SDK überhaupt nicht, darunter solche, die vor seiner Initialisierung ausgelöst werden, solche aus Cross-Origin-Skripten ohne CORS-Header und solche innerhalb von iframes. Für jeden gibt es einen Workaround, aufgeführt unter [Fehler, die nicht gemeldet werden](/browser/error-tracking#errors-that-are-not-reported). Wenn ein erwarteter Fehler fehlt, arbeiten Sie die [Fehlerbehebung](/browser/troubleshooting#an-error-is-missing) durch.
