JavaScript-Fehler im Frontend überwachen (first-party)

Warum serverseitige Checks JS-Fehler nicht sehen

Klassisches Monitoring prüft, ob ein Server erreichbar ist und mit welchem Statuscode er antwortet. Eine Seite kann jedoch mit HTTP 200 ausgeliefert werden, das HTML vollständig laden - und dann erst im Browser des Besuchers zerbrechen, weil ein Skript einen Laufzeitfehler wirft. Der Server hat seine Aufgabe erfüllt, der Fehler entsteht ausschließlich auf dem Endgerät. Genau diese Klasse von Störungen ist für serverseitige Prüfungen unsichtbar, weil sie gar nicht erst beim Server ankommt.

Die Datenlage unterstreicht, wie verbreitet das Problem ist. Eine empirische Untersuchung produktiver Websites stellte fest, dass JavaScript-Fehler in einer kleinen Zahl von Kategorien auftreten und sowohl deterministisch als auch nicht-deterministisch sein können - sie hängen also teils vom konkreten Browser, Gerät und Nutzerpfad ab (UBC-Studie Ocariza et al.). Ein Fehler, der im Test-Browser des Entwicklers nicht auftritt, kann auf einem älteren Mobilgerät dennoch zuverlässig zuschlagen. Wer nur am eigenen Laptop testet, sieht diese Vielfalt in der Regel nicht.

Erschwerend kommt hinzu, dass moderne Seiten stark von Skripten abhängen. Eingebundene Bibliotheken, Tag-Manager, Widgets und Frameworks bringen jeweils eigenen Code mit - jede dieser Quellen kann eine Ausnahme werfen, die den weiteren Skriptablauf stoppt. Verwandte stille Störungen im Frontend behandelt auch der Beitrag zur Überwachung von CORS-Konfigurationsfehlern, denn ein durch CORS abgewiesener Request endet oft als ebenso unsichtbarer JavaScript-Fehler.

Wie der Browser Fehler meldet: onerror und unhandledrejection

Der Browser stellt zwei zentrale Mechanismen bereit, um Laufzeitfehler abzufangen. Der globale window.onerror-Handler erhält synchron geworfene Ausnahmen und liefert Nachricht, Quelle, Zeile, Spalte und das Error-Objekt (MDN Web Docs). Asynchrone Fehler aus nicht behandelten Promises landen dagegen im unhandledrejection-Event (MDN Web Docs). Erst beide zusammen decken den Großteil der unbehandelten Fehler ab.

Eine belastbare Frontend-Erfassung kombiniert daher mehrere Quellen: den globalen onerror-Handler für synchrone Ausnahmen, den unhandledrejection-Listener für fehlgeschlagene Promises, eine Erfassung von Netzwerkfehlern sowie - bei Bedarf - Framework-spezifische Fehlergrenzen (Inspectlet 2026). Wer nur eine dieser Quellen abhört, übersieht systematisch eine ganze Fehlerklasse.

// Synchrone Laufzeitfehler
window.addEventListener('error', (e) => {
  report({
    kind: 'error',
    message: e.message,
    source: e.filename,
    line: e.lineno,
    col: e.colno,
    stack: e.error && e.error.stack
  });
});

// Nicht behandelte Promise-Rejections
window.addEventListener('unhandledrejection', (e) => {
  report({
    kind: 'unhandledrejection',
    message: String(e.reason && e.reason.message || e.reason)
  });
});

In der Praxis stößt eine selbst gebaute Lösung schnell an Grenzen. Fehler aus Skripten anderer Herkunft werden vom Browser aus Sicherheitsgründen auf die generische Meldung Script error. reduziert - ohne crossorigin-Attribut und passende CORS-Header fehlen Stacktrace und Detailinformation (MDN Web Docs). Minifizierter Produktionscode liefert zudem kryptische Positionen wie checkout.min.js:1:48213, die ohne Source-Maps kaum einem konkreten Codeort zuzuordnen sind (Rollbar). Eine reine Sammlung von Roh-Events ist deshalb wenig wert - es kommt auf Anreicherung, Gruppierung und Trend-Auswertung an.

First-party statt Drittanbieter-Skript

Viele Fehler-Tracking-Ansätze laden ein externes Skript von einer fremden Domain. Das ist aus zwei Gründen heikel: Erstens ist genau dieses Skript ein weiterer Drittanbieter-Tracker, der datenschutzrechtlich behandelt werden muss; zweitens werden Skripte mit bekannten Tracker-Dateinamen von Browser-Erweiterungen und Filterlisten häufig blockiert - dann fehlen ausgerechnet die Fehler der Nutzer mit aktivem Blocker. First-party bedeutet, dass die Erfassung von Ihrer eigenen Domain ausgeliefert wird und Daten an Ihre eigene Infrastruktur fließen.

XICTRAQ erfasst JavaScript-Fehler über den ohnehin eingebundenen, cookielosen First-Party-Tracker. Derselbe Mechanismus, der Seitenaufrufe und Web Vitals misst, hört auch onerror und unhandledrejection ab und sendet die Ereignisse an Ihre eigene Auswertung. Dadurch entsteht kein zusätzlicher Drittanbieter, und die Fehlerdaten stehen im selben Dashboard wie die übrigen Kennzahlen. Wie eng Frontend-Qualität und Ladeverhalten zusammenhängen, zeigt auch der Beitrag zum kontinuierlichen Accessibility-Monitoring nach WCAG - beides sind Aspekte, die ein reiner Server-Check nicht erfasst.

Ein häufiger Einwand lautet, man sehe Fehler doch bereits in den Logs des Servers oder in der Browser-Konsole während der Entwicklung. Beides greift jedoch zu kurz. Server-Logs enthalten clientseitige Ausnahmen prinzipbedingt nicht, weil diese den Server gar nicht erst erreichen. Und die Konsole zeigt nur, was auf dem einen Gerät sichtbar wird, an dem gerade jemand sitzt - sie sagt nichts darüber, wie oft ein Fehler in der realen Nutzerschaft auftritt, welche Browser-Versionen betroffen sind oder ob die Häufigkeit nach einem Release gestiegen ist. Erst die aggregierte Sicht über viele echte Sitzungen hinweg macht aus einzelnen Beobachtungen eine belastbare Aussage über die Frontend-Gesundheit.

Was XICTRAQ am Frontend überwacht

Frontend-Monitoring ist mehr als das Sammeln von Fehlermeldungen. Es geht darum, aus rohen Ereignissen ein verständliches Bild zu machen: Welcher Fehler trifft wie viele Nutzer, auf welcher Seite, in welchem Browser, seit welchem Release. Die folgende Übersicht zeigt die Signale, die zusammen ein belastbares Bild der Frontend-Gesundheit ergeben.

Entscheidend ist die Normierung auf die Fehlerrate je Seitenaufruf. Eine absolute Fehlerzahl steigt zwangsläufig mit dem Traffic - 500 Fehler an einem Aktionstag können völlig normal sein, 50 Fehler nachts dagegen ein Alarmsignal. Erst die Rate macht Zeiträume und Seiten vergleichbar und legt die Grundlage für eine verlässliche Anomalie-Erkennung.

Frontend-Fehler richtig priorisieren

Nicht jeder erfasste Fehler verdient die gleiche Aufmerksamkeit. Im Browser entsteht eine erhebliche Menge an Rauschen, das mit der eigentlichen Anwendung wenig zu tun hat: Eine Browser-Erweiterung injiziert Code, der scheitert; ein Werbe-Blocker bricht einen Request ab; ein veralteter Browser kennt eine genutzte Funktion nicht. Solche Ereignisse als kritische Fehler zu behandeln, führt zu Alarm-Müdigkeit - dem Zustand, in dem ein Team Warnungen ignoriert, weil zu viele davon belanglos sind. Ein belastbares Frontend-Monitoring trennt deshalb das Signal vom Rauschen, statt jede Konsolenmeldung gleich zu gewichten.

Die Priorisierung folgt typischerweise drei Fragen. Erstens: Wie viele Nutzer sind betroffen? Ein Fehler auf 30 Prozent der Sitzungen wiegt schwerer als ein Einzelfall. Zweitens: Wo passiert er? Ein Fehler im Checkout oder im Login-Formular ist geschäftskritisch, ein Fehler auf einer selten besuchten Archivseite weniger. Drittens: Seit wann tritt er auf? Ein Fehler, der mit dem letzten Deploy auftauchte, deutet auf eine frische Regression hin und sollte zuerst geprüft werden. Genau diese Dimensionen - Häufigkeit, Ort und zeitlicher Bezug - liefert eine gruppierte, angereicherte Erfassung von Haus aus, während eine reine Liste roher Konsolenmeldungen sie verschweigt.

In der Praxis hilft ein einfaches Vorgehen: Zuerst die Fehler nach betroffenen Sitzungen sortieren, dann die geschäftskritischen Seiten zuerst betrachten und schließlich prüfen, ob ein Anstieg mit einem Release zusammenfällt. So entsteht eine Rangliste, die nicht der lautesten Konsolenmeldung folgt, sondern dem tatsächlichen Schaden. Diese Arbeitsweise hält den Aufwand beherrschbar, auch wenn täglich neue Einträge hinzukommen - denn behandelt wird nur, was Nutzer und Umsatz spürbar betrifft. Genauso wichtig ist, einen einmal behobenen Fehler im Auge zu behalten: Taucht er nach einem späteren Release erneut auf, ist das ein deutliches Zeichen für eine zurückgekehrte Regression, die ohne kontinuierliche Beobachtung leicht ein zweites Mal unbemerkt bliebe. Eine dauerhafte Verlaufsansicht macht solche Rückfälle sichtbar und trennt sie von echten Neufunden.

Fehlerrate-Anomalien nach Deploys erkennen

Die häufigste Ursache eines plötzlichen Anstiegs der Frontend-Fehler ist ein Deploy. Ein geändertes Skript, eine aktualisierte Abhängigkeit oder ein umbenanntes DOM-Element - und schon wirft Code eine Ausnahme, die es vorher nicht gab. Da leistungsstarke Web-Teams häufig releasen, gibt es viele Gelegenheiten für solche Regressionen. Genau hier hilft die kontinuierliche Beobachtung der Fehlerrate: Statt auf eine feste Schwelle zu warten, vergleicht das Monitoring den aktuellen Wert mit einer gelernten Baseline aus den Vorwochen und schlägt an, wenn die Rate signifikant darüber springt.

Baseline (Mo-Do, je 1.000 Seitenaufrufe):
  6,8  Fehler/1k   normaler Bereich (Mittel 7,1, Sigma 1,4)

Nach Deploy v42 (Fr 09:14):
  09:20   8,1  Fehler/1k   noch im Rahmen
  09:28  21,4  Fehler/1k   über Schwelle (Mittel + 3 Sigma)
  09:30  31,0  Fehler/1k   +340 % gegenüber Baseline

  Top-Fehler:  TypeError: cannot read 'total'  (62 %)
  Browser:     Safari iOS 17                    (88 %)
  Seite:       /checkout

=> Anomalie 14 Min nach Deploy v42 - Alert ausgelöst

Der Mehrwert liegt im Zusammenspiel von Erkennung und Kontext. Der Alert meldet nicht nur, dass die Fehlerrate gestiegen ist, sondern liefert gleich die Diagnose mit: welcher Fehlertyp dominiert, welcher Browser betroffen ist und auf welcher Seite es passiert. Im Beispiel zeigt sich sofort, dass ein TypeError im Checkout vor allem Safari auf iOS trifft - eine Spur, die das Team direkt zum verursachenden Release führt. Dasselbe Prinzip der Soll-Ist-Abweichung nutzt auch die Überwachung von API-Rate-Limits und 429-Antworten, wo ein plötzlicher Anstieg ebenfalls auf eine frische Regression hindeutet.

Warum schnelle Reaktion Umsatz schützt

Frontend-Fehler kosten doppelt: direkt durch abgebrochene Transaktionen und indirekt durch Vertrauensverlust. Eine Befragung ergab, dass 51 % der mobilen Internetnutzer schon eine Website erlebt haben, die abgestürzt ist, eingefroren hat oder einen Fehler zeigte (Google/Search Engine People). Solche Erlebnisse führen selten zu einer Beschwerde - meist verlassen Nutzer die Seite kommentarlos. Der Schaden entsteht still und bleibt ohne Monitoring unsichtbar.

Auch die Nähe zu Performance-Kennzahlen ist relevant. Seiten, die in zwei Sekunden oder schneller laden, haben eine Absprungrate von rund 9 %, während Seiten mit fünf Sekunden Ladezeit auf rund 38 % steigen (Google). Layout-Verschiebungen und blockierende Skripte - häufig Folge von JavaScript-Problemen - verschlechtern diese Werte zusätzlich und können zu Fehlklicks und verpassten Conversions führen (web.dev). Fehler und Performance sind daher kein getrenntes Thema, sondern zwei Seiten derselben Frontend-Gesundheit.

Der Unterschied ist nicht nur die Geschwindigkeit, sondern die Qualität der Information. Eine Nutzer-Beschwerde liefert bestenfalls "der Button geht nicht"; ein Anomalie-Alert liefert Fehlertyp, betroffenen Browser und Seite. Damit entfällt die zeitraubende Reproduktion, und das Team kann direkt am verursachenden Release ansetzen.

1. Erfassen - onerror und unhandledrejection first-party von der eigenen Domain abhören
2. Anreichern - Browser, Version, Gerät, Seite und Zeitpunkt an jeden Fehler hängen
3. Normieren - Fehler je 1.000 Seitenaufrufe statt absoluter Zahlen betrachten
4. Gruppieren - gleichartige Fehler zusammenfassen, damit Massenfehler sichtbar werden
5. Alarmieren - bei signifikanter Abweichung von der Baseline benachrichtigen, mit Diagnose

Frontend-Monitoring als Teil des Gesamtbilds

JavaScript-Fehler sind ein Baustein eines vollständigen Website-Monitorings. Ein Server kann erreichbar sein, das Zertifikat gültig, die DNS-Konfiguration sauber - und trotzdem scheitert der Kunde an einem Skriptfehler. Umgekehrt nützt ein technisch einwandfreies Frontend wenig, wenn die DNSSEC-Validierung der DNS-Sicherheit versagt oder Verweise ins Leere laufen, wie der Beitrag zum automatisierten 404- und Broken-Link-Monitoring zeigt. Erst die Kombination dieser Signale ergibt ein belastbares Bild.

Der praktische Wert liegt darin, all diese Ebenen in einer Oberfläche zusammenzuführen. Wenn Fehlerrate, Uptime, Zertifikatsstatus und Performance nebeneinander stehen, lässt sich eine Störung schnell der richtigen Ebene zuordnen - statt zwischen mehreren Werkzeugen zu raten. Frontend-Fehler-Monitoring ergänzt das klassische Verfügbarkeits-Monitoring genau dort, wo dieses blind ist: auf dem Endgerät des Besuchers. Für Teams bedeutet das vor allem weniger Reibung im Alltag. Wer eine Störungsmeldung erhält, sieht sofort, ob es sich um einen Ausfall der Erreichbarkeit, ein abgelaufenes Zertifikat oder einen Skriptfehler im Browser handelt, und kann die zuständige Person gezielt einbinden. Das verkürzt nicht nur die technische Fehlersuche, sondern auch die organisatorische Klärung, wer überhaupt handeln muss - ein Aspekt, der in der Praxis oft mehr Zeit kostet als die eigentliche Behebung.

Ein Deploy lässt sich nicht verhindern, und das soll er auch nicht - schnelle Releases sind ein Vorteil. Verhindern lässt sich aber, dass eine Frontend-Regression stundenlang unbemerkt Umsatz kostet. Genau dafür ist first-party JavaScript-Fehler-Monitoring gedacht: Es macht aus dem unsichtbaren Fehler im Browser ein sichtbares, alarmierbares Signal.

Häufig gestellte Fragen zum JavaScript-Fehler-Monitoring