Irgendwo in deinem Support-Tool gibt es eine Textvorlage, die so lautet: „Könnten Sie F12 drücken, den Tab Console öffnen und uns einen Screenshot von allem roten Text schicken?“ Sie geht ein paarmal pro Woche raus. Fast nie kommt etwas Brauchbares zurück, und jeder Fix, der davon abhängt, steht tagelang still, während der Thread einschläft.
Hier geht es darum, diese Vorlage in Rente zu schicken. Nicht, indem du Nutzenden DevTools beibringst, sondern indem beim nächsten „die Seite ist kaputt“ die Console-Fehler und fehlgeschlagenen Requests aus ihrer Session schon im Bericht liegen.
Warum die Bitte um DevTools nie funktioniert
Die Textvorlage scheitert aus Gründen, die nichts mit dem guten Willen der Nutzenden zu tun haben:
Die meisten haben DevTools nie gesehen. Das Tastenkürzel unterscheidet sich je nach Plattform und Browser, der Tab Console ist einer von einem Dutzend, und rote Stacktraces wirken wie Rauschen. Du verlangst von jemandem, ein Profiwerkzeug zu bedienen, einmalig, ohne dass jemand danebensitzt, per E-Mail.
Die Belege sind schon weg. Die Console-Ausgabe lebt genau so lange wie der Tab. Bis deine Antwort ankommt, hat die Person die Seite geschlossen, und der Fehler, den du gebraucht hättest, existiert nirgends mehr. Jetzt bittest du sie, den Bug auf Kommando zu reproduzieren, also genau das, was du selbst nicht schaffst.
Ein Screenshot ist das falsche Format. Selbst im besten Fall bekommst du das Bild eines eingeklappten Stacktraces, so beschnitten, dass genau die eine wichtige Zeile fehlt, ohne Zeitstempel und ohne Netzwerkkontext. Du kannst ihn nicht durchsuchen, nicht aufklappen und mit nichts abgleichen.
Rechnet man die Rückfragerunden zusammen, kostet die Bitte um DevTools tagelange Verzögerung und bringt bestenfalls einen Bruchteil dessen, was der Browser im Moment des Fehlers ohnehin wusste.
Dreh die Richtung um: Der Browser berichtet, die Person beschreibt nur
Hör auf, Belege über das Gedächtnis und die Screenshots der Nutzenden zu leiten, und hol sie dort ab, wo sie schon existieren: im Browser, im Moment des Bugs.
Genau das macht ein Widget für Fehlerberichte. Ist BugDump installiert, läuft die Erfassung schon, bevor etwas kaputtgeht: Das SDK hält beim Surfen ein rollierendes Fenster der letzten Console-Einträge und der Netzwerkaktivität vor. Stößt jemand auf ein Problem, klickt die Person auf den Bug-Button und tippt einen Satz in eigenen Worten. Dieser Satz ist ihre ganze Aufgabe. Alles, wonach du sonst gefragt hättest, kommt automatisch mit:
Console-Logs: die letzten 300 Einträge, Fehler und Warnungen markiert, im Dashboard durchsuchbar. Nicht abgefangene Exceptions und unbehandelte Promise-Rejections werden ebenfalls erfasst, auch die, die dein Code nie geloggt hat.
Netzwerk-Requests: die letzten 150, mit Methode, Statuscode und Timing, Fehlschläge hervorgehoben. Die 500, die dem sichtbaren Fehler vorausging, steht direkt daneben.
Umgebung: Browser, Betriebssystem, Gerät, Viewport und die genaue URL der Seite, sodass nie wieder jemand „Welchen Browser benutzen Sie?“ tippen muss.
Session-Replay: eine Rekonstruktion zum Durchspulen, die zeigt, was die Person bis zum Bericht getan hat. Wichtig bei Bugs, deren Ursache die Klickfolge ist.
Entscheidend ist die Reihenfolge. Jeder Ablauf, der erst nach der Entscheidung zum Melden mit dem Sammeln beginnt, hat den Fehler schon verpasst. Weil die Puffer ständig laufen, ist der Moment des Fehlers erfasst, obwohl niemand wusste, dass gleich ein Bug passiert, die Person vor dem Bildschirm am allerwenigsten.
Einen Bericht lesen: die Diagnose in zwei Minuten
Ein Bericht mit angehängter Telemetrie wird in einer bestimmten Reihenfolge gelesen, und das geht schnell:
Lies den Satz der Person. Er verrät dir die Absicht („Ich wollte bezahlen“).
Spring zu den markierten Einträgen: zur nicht abgefangenen Exception in der Console, zum fehlgeschlagenen Request in der Netzwerkliste.
Prüf, was direkt davor passiert ist: der Request, der unerwartete Daten zurückgab, die Warnung bei der vorherigen Aktion.
Wenn die Abfolge wichtig ist, spul durch das Replay, um zu sehen, was die Person tatsächlich angeklickt hat.
Der Console-Fehler benennt das Symptom in deinem Code, das Netzwerk-Log meist die Ursache, und das Replay klärt den Streit darüber, was „ich hab ganz normal geklickt“ bedeutet. Die meisten Berichte kommen von „geöffnet“ zu „ich weiß, welche Datei ich öffnen muss“, ohne eine einzige Nachricht an die Person. Die klärende Rückfragerunde, die früher Tage dauerte, findet einfach nicht statt.
Einrichtung
Die Installation ist eine Zeile auf jeder Website, ohne Build-Schritt und ohne Framework-Adapter:
<script src="https://bugdump.com/sdk/latest.js" async data-api-key="your-api-key"></script>Zwei Ergänzungen lohnen sich vom ersten Tag an. Hat deine App eingeloggte Nutzende, ruf nach dem Login bugdump('identify', { email }) auf, damit jeder Bericht zeigt, wer ihn gemeldet hat. Und wenn auf deinen Seiten gesprächige fremde Skripte laufen (Analytics-Beacons, Feature-Flag-Abfragen), setz im SDK consoleFilter und networkFilter, damit die Puffer die Aktivität deiner App enthalten und kein Heartbeat-Rauschen. Gefilterte Einträge verlassen den Browser nie, die Filter dienen also dem Datenschutz genauso wie der Ordnung. Request- und Response-Bodies sind standardmäßig aus (captureNetworkBodies schaltet sie ein). Lass sie aus, solange du keinen konkreten Grund hast, und erwähne in deiner Datenschutzerklärung, dass Fehlerberichte Diagnose-Logs enthalten.
Prüf dann den ganzen Ablauf: Schick einen Bericht von deiner eigenen Website, öffne ihn im Dashboard und sieh nach, ob die Console- und Netzwerk-Panels deine Session zeigen. Dieser Zwei-Minuten-Test ist genau das, was deine Nutzenden erleben werden.
Schick die Textvorlage in Rente
Die Textvorlage verschwindet nicht ganz, sie wird kürzer. „Könnten Sie auf der Seite auf den Bug-Button klicken und einen Bericht senden?“ ist eine Bitte in einer Zeile, die man tatsächlich erfüllen kann. Zurück kommt kein beschnittener Screenshot, sondern Console, Netzwerk-Log, Umgebung und Replay aus dem Moment, in dem es kaputtging.
Fehler liest du weiterhin jeden Tag. Nur eben im Dashboard, aus den Browsern, in denen die Bugs wirklich passiert sind, statt Nutzende zu bitten, roten Text zu beschreiben, der nie für sie gedacht war.
So erfasst du Console-Logs und Netzwerk-Requests aus fremden Browsern – wie du Console, Fehler, fetch und XHR instrumentierst und welche Fallen dabei die überwachte Seite kaputt machen.
Session-Replay zum Debuggen: was vor dem Bug passiert ist – wie Session-Replay funktioniert, was es erfasst und warum es zusammen mit Console- und Netzwerk-Logs vage Berichte diagnostizierbar macht.
Was tun mit einem Fehlerbericht, den du nicht reproduzieren kannst – die üblichen Ursachen, der Kontext, der sie aufklärt, und wie du verhinderst, dass sie wiederkommen.