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

# Fehlerbehebung für browser monitoring

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

<h2 id="no-data-arrives-at-all">
  Es kommen überhaupt keine Daten an
</h2>

Arbeiten Sie diese Punkte der Reihe nach durch. Jeder davon ist ein vollständiger Stopp: Wenn er zutrifft, wird nichts gesendet.

1. **`active` ergibt `false`.** Loggen Sie den Wert, den Sie übergeben, nicht den Ausdruck. Ein Bundler, der `process.env.NODE_ENV` nicht ersetzt, lässt den Vergleich im Browser `false` werden.
2. **`init()` wurde nie ausgeführt.** Konfiguration zu setzen genügt nicht. Bestätigen Sie, dass Ihr Entry Point das Modul importiert, das `init()` aufruft. Prüfen Sie, dass Ihr Build es enthält.
3. **Der Schlüssel ist falsch.** Ein falscher Schlüssel führt zu `401`. Verwenden Sie den [Front-end API key](/browser/installation#find-your-front-end-api-key) dieser App, keinen Push key. Prüfen Sie, dass er zur richtigen Umgebung gehört.
4. **Requests werden blockiert.** Öffnen Sie das Netzwerk-Panel Ihres Browsers und suchen Sie nach einem Request an `/ingest/browser/errors` für Fehler oder `/ingest/browser` für web vitals. Ein blockierter Request erscheint in der Konsole als Verstoß gegen die Content Security Policy: Fügen Sie `https://appsignal-endpoint.net` zu Ihrer `connect-src`-Direktive hinzu.
5. **`endpoint` ist nicht gesetzt.** Ohne `endpoint` sendet das SDK an die aktuelle Origin. Das erfordert einen Proxy auf Ihrer Domain. Setzen Sie es andernfalls auf `https://appsignal-endpoint.net`.

<h2 id="errors-arrive-web-vitals-do-not">
  Fehler kommen an, web vitals nicht
</h2>

Web vitals werden gestapelt und nicht pro Messung gesendet. Sie werden gesendet, wenn die Seite verborgen wird, wenn sie geschlossen wird und bei einem clientseitigen Routenwechsel. Verlassen Sie die Seite oder wechseln Sie den Tab, und prüfen Sie die Performance-Ansicht erneut.

Wenn sie dann noch fehlen, prüfen Sie, ob es speziell CLS und INP sind, die fehlen. Diese beiden benötigen Browser-Performance-Entries, die möglicherweise [nicht verfügbar](/browser/web-vitals#browser-support) sind.

<h2 id="an-error-is-missing">
  Ein Fehler fehlt
</h2>

* **Er trat auf, bevor `init()` lief.** Nichts, was davor ausgelöst wird, wird erfasst. Importieren Sie Ihr AppSignal-Setup als ersten Import in Ihrem Entry Point.
* **Er war eine Wiederholung.** Prüfen Sie die [Rate-Limits](/browser/error-tracking#rate-limits) für identische und für alle Fehler.
* **Er wurde per sampling verworfen.** Prüfen Sie, ob `errors.sampleRate` unter `1.0` liegt.
* **`beforeError` hat ihn verworfen.** Ein Callback, der `null` zurückgibt, verwirft den Fehler. Loggen Sie das Event am Anfang des Callbacks, um zu bestätigen, was es erhält.
* **Er wurde in einem [iframe](/browser/error-tracking#errors-that-are-not-reported) ausgelöst.** Ein Same-Origin-iframe braucht seinen eigenen `init()`-Aufruf.
* **Es war ein React-Render-Fehler.** React lässt Render-Fehler nicht bis zu `window` durch. Fügen Sie eine [Error Boundary](/browser/react) hinzu.
* **Er kam von einem Skript auf einer anderen Domain.** Lesen Sie den folgenden Abschnitt.

<h2 id="errors-show-up-with-no-message-or-stack">
  Fehler von Cross-Origin-Skripten fehlen
</h2>

Wenn Fehler aus einem Skript fehlen, das auf einem anderen Origin gehostet wird, prüfen Sie dessen Cross-Origin-Einstellungen. Der Browser zeigt für Cross-Origin-Skripte möglicherweise nur `Script error.` an. Das SDK verwirft diese nichtssagenden Fehler. Beheben Sie es, indem Sie diese Skripte mit CORS-Headern ausliefern, wie unter [Assets auf einem CDN](/browser/installation#assets-hosted-on-a-cdn) beschrieben.

<h2 id="backtraces-are-minified">
  Backtraces sind minifiziert
</h2>

Backtraces werden über [sourcemaps](/front-end/sourcemaps) aufgelöst, abgeglichen über den Revisions-String. Setzen Sie `appVersion` auf denselben Wert, den Ihr Build für seine sourcemaps verwendet. Ohne `appVersion` gibt es nichts, worüber abgeglichen werden könnte, und Backtraces bleiben minifiziert.

<h2 id="one-route-produces-hundreds-of-error-groups">
  Eine Route erzeugt Hunderte von Fehlergruppen
</h2>

Das [Route-Template](/browser/installation#report-the-current-route) fehlt, daher verwenden Fehler den rohen Pfad jeder Seite. Rufen Sie bei jeder Router-Navigation `setRouteTemplate("/orders/:id")` auf. Neue Fehler gruppieren sich dann unter diesem Template. Für web vitals leitet der Server ein angenähertes Template ab. Ein explizites Template ist zuverlässiger und hilft, das Limit für unterschiedliche Routen zu vermeiden.

<h2 id="client-side-navigation-is-not-reported">
  Clientseitige Navigation wird nicht gemeldet
</h2>

Das SDK und manche Router patchen beide `history.pushState`. Das SDK verträgt sich mit einem bereits installierten Patch. Ein Router, der den Patch des SDKs später ersetzt, kann das Tracking der Navigation unterbrechen. Importieren Sie Ihr AppSignal-Setup vor Ihrem Router.

Hash-Router werden nur als Router behandelt, wenn der Hash wie eine Route aussieht, etwa `#/orders`. Ein bloßes `#orders` ist von einem Anker innerhalb der Seite nicht zu unterscheiden und wird nicht als Navigation behandelt.

<h2 id="api-requests-fail-after-enabling-distributed-tracing">
  API-Requests schlagen nach Aktivierung von verteiltem Tracing fehl
</h2>

Ein Cross-Origin-Request, der `traceparent` mitführt, benötigt möglicherweise einen CORS-Preflight. Wenn Ihr Browser einen CORS-Fehler meldet, der `traceparent` nennt, erlauben Sie diesen Header in `Access-Control-Allow-Headers` Ihrer API. Mehr dazu unter [Verteiltes Tracing für Browser](/browser/distributed-tracing#enable-it).

<h2 id="a-failed-request-shows-no-back-end-spans">
  Ein fehlgeschlagener Request zeigt keine Back-end-Spans
</h2>

Der Fehler ist angekommen, aber sein Trace enthält nur den Browser-Span. Prüfen Sie, dass der empfangende Service über einen gehosteten Collector berichtet. Sein HTTP-Server braucht außerdem das [richtige Instrumentierungspaket](/browser/distributed-tracing#before-you-start), um `traceparent` zu lesen.

<h2 id="no-failed-requests-are-reported">
  Keine fehlgeschlagenen Requests werden gemeldet
</h2>

Requests an Ihre API schlagen fehl, aber es erscheint kein `HTTPError`- oder `TimeoutError`-Issue. Prüfen Sie, dass jeder Request einem Muster in `tracePropagationTargets` entspricht. Ein Muster braucht einen Host und einen Pfad: Weder `/api/**` noch `api.example.com` allein passen auf irgendetwas. Manche Fehlschläge werden nie gemeldet:

* Ein Request im `no-cors`-Modus.
* Eine 4xx-Antwort.
* Ein Request, der auf `privacy.networkBlocklist` passt.
* Ein Timeout, während das Gerät offline ist.

Mehr dazu unter [was gemeldet wird](/browser/distributed-tracing#what-is-reported).

<h2 id="network-breadcrumbs-have-no-timings">
  Netzwerk-Breadcrumbs haben keine Zeitangaben
</h2>

Der Request war cross-origin und der Server hat keinen `Timing-Allow-Origin`-Header gesendet. Mehr dazu unter [Netzwerk-Breadcrumbs lesen](/browser/breadcrumbs#reading-network-breadcrumbs).

<h2 id="getting-help">
  Hilfe bekommen
</h2>

Geben Sie den Namen Ihrer App, die Version von `@appsignal/browser` sowie Browser und Version an, in denen Sie das Problem sehen. Erreichen Sie uns über [unsere Support-Kanäle](/support) oder für Beta-Feedback in unserer [Discord-Community](https://discord.gg/EjF6ykYx63).


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