So fügst du deiner Website einen Button für Fehlerberichte hinzu

widgetDenis Povarov30. August 2026

Ein Button für Fehlerberichte auf deiner Website macht eine Sache gut: Er fängt Probleme in dem Moment ein, in dem Nutzende darauf stoßen, auf der Seite, auf der es passiert, statt darauf zu hoffen, dass später jemand deine Support-Adresse heraussucht. Hier geht es Schritt für Schritt darum, einen solchen Button mit BugDump einzubauen: von der Einrichtung in einer Zeile bis zu den Optionen, die in Produktion zählen.

Option 1: das Script-Tag (empfohlen)

Füg deinem HTML eine Zeile hinzu, am besten gegen Ende von head oder body:

<script src="https://bugdump.com/sdk/latest.js" async data-api-key="your-api-key"></script>

Das ist die gesamte Integration. Das Attribut data-api-key löst die automatische Initialisierung aus: kein JavaScript schreiben, kein Build-Schritt, kein Framework-Adapter. Ein schwebender Bug-Button erscheint in der Ecke jeder Seite, auf der das Tag steht.

Das Attribut async ist wichtig: Es verhindert, dass das SDK das Parsen der Seite oder DOMContentLoaded blockiert. Das Widget initialisiert sich, sobald das Skript da ist, aber deine Seite wartet nie darauf. Das Entry-Skript ist etwa 118 KB groß (rund 28 KB mit gzip). Schwerere Teile wie die Bibliothek für DOM-Screenshots und das Session-Replay-Modul sind eigene Chunks, die erst geladen werden, wenn sie tatsächlich gebraucht werden. Seiten, die sie nie brauchen, laden sie also nie herunter.

Weil das Widget in einem Shadow DOM lebt, kann das CSS deiner Website es nicht kaputt machen, und seine Styles sickern nicht in dein Layout. Bei älteren eingebetteten Widgets ist genau das ein echtes Problem.

Option 2: npm

Wenn du das SDK lieber als gebündelte, versionierte Abhängigkeit hast:

npm install @bugdump/sdk

import { Bugdump } from '@bugdump/sdk';

const bugdump = Bugdump.init({ apiKey: 'your-api-key' });

Du bekommst vollständige TypeScript-Definitionen, sodass dein Editor dir alle Konfigurationsoptionen anzeigt. Dieser Weg passt zu Apps, in denen jedes fremde Skript durch das Bundle und das Dependency-Review geht.

Option 3: manuelle Initialisierung mit Befehlswarteschlange

Für Websites, die das Skript asynchron laden, das SDK aber sofort aufrufen müssen, also bevor der Download fertig ist, gibt es das Stub-Muster:

<script>
  window.bugdump = window.bugdump || function () {
    (window.bugdump.q = window.bugdump.q || []).push(arguments);
  };
</script>
<script src="https://bugdump.com/sdk/latest.js" async></script>
<script>
  bugdump('init', { apiKey: 'your-api-key' });
  bugdump('identify', { email: 'user@example.com' });
</script>

Bis das SDK da ist, stellt bugdump(...) Aufrufe in eine Warteschlange. Sobald es geladen ist, werden sie der Reihe nach ausgeführt. Ohne den Stub würde ein Inline-Aufruf mit dem asynchronen Download um die Wette laufen und einen Fehler werfen. Analytics-Snippets nutzen dasselbe Muster, und es ist die richtige Wahl, wenn die Init-Optionen vom Laufzeitzustand abhängen: von der eingeloggten Person, einem Feature-Flag, dem Seitentyp.

Konfiguration, die du am ersten Tag setzen solltest

Die Standardwerte sind vernünftig, aber ein paar Optionen verdienen eine bewusste Entscheidung:

theme: 'light', 'dark' oder 'auto' (folgt dem Betriebssystem). Hat deine App einen eigenen Theme-Umschalter, pass das Widget daran an.
Identifiziere deine Nutzenden. Bei Apps mit Konten ruf nach dem Login bugdump('identify', { email }) auf. Berichte kommen dann mit der meldenden Person an, und niemand muss im Widget die eigene E-Mail-Adresse eintippen.
bubbleText: ein Hinweis neben dem Button, den man wegklicken kann („Bug gefunden?“). Nützlich während einer Beta, wenn du aktiv Berichte willst. Ob er weggeklickt wurde, merkt sich das Widget pro Browser.
hideButton: blendet den schwebenden Button aus, und du öffnest das Widget mit bugdump('open') aus deiner eigenen Oberfläche, etwa über einen Eintrag „Problem melden“ im Hilfemenü. So bleibt die Seite aufgeräumt, und das Melden ist trotzdem nur einen Klick entfernt.
translations: überschreibt jeden Text im Widget. Ist dein Produkt nicht auf Englisch, sollte es der Melde-Button auch nicht sein.

Rauschen filtern, bevor es dich etwas kostet

Das Widget führt Ringpuffer für Console-Einträge und Netzwerk-Requests, damit jeder Bericht die jüngste Vorgeschichte mitbringt. Auf Seiten mit gesprächigen fremden Skripten (Analytics-Beacons, Feature-Flag-Abfragen, Health-Checks) füllt sich diese Vorgeschichte mit Rauschen, und Rauschen verdrängt das Signal.

Konfiguriere consoleFilter und networkFilter, um irrelevante Einträge zu verwerfen, bevor sie in die Puffer gelangen. Das bringt zwei Vorteile: Die Einträge, die dich interessieren, überleben, bis der Bericht gesendet wird, und fremder Traffic, den du lieber nicht speicherst, verlässt den Browser nie. Aktivierst du captureNetworkBodies, dient das Filtern dem Datenschutz genauso wie der Ordnung. Entscheide ausdrücklich, welche Endpoints ihre Bodies in einen Fehlerbericht schreiben dürfen.

Stolperfallen

Versteck den Button nicht hinter einem Formular. Jedes Pflichtfeld kostet Berichte. Nur die Beschreibung lohnt sich als Pflichtfeld. Umgebung, Console, Netzwerk und Replay-Daten werden automatisch gesammelt, und genau darum geht es.
Denk an deine Content-Security-Policy. Eine strenge CSP braucht den Ursprung des SDK in script-src. Das SDK lädt seine optionalen Chunks vom selben Ursprung, es reicht also nicht, nur die Entry-Datei zu erlauben.
Wenn du das SDK selbst hostest oder über einen Proxy auslieferst, kopiere alle seine Dateien, nicht nur die Entry-Datei. Sie löst ihre Screenshot- und Replay-Chunks relativ zu ihrer eigenen URL auf. Lieferst du sie allein aus, sind diese Funktionen stillschweigend kaputt, während der Rest des Widgets zu funktionieren scheint.
Liefere es nicht nur in Produktion aus. Bau das Widget auch auf Staging ein, mit einem eigenen API-Key für das Projekt. Dein Team nutzt den eigenen Meldeablauf als Erstes, und Konfigurationsfehler fallen auf, bevor echte Nutzende sie sehen.

Prüfen, ob es funktioniert

Schick nach der Installation selbst einen Bericht: Klick auf den Button, mach einen Screenshot, markiere etwas darauf und sende ab. Öffne den Bericht dann im Dashboard und prüf, ob Console-Logs, Netzwerk-Requests und Umgebungsdaten angekommen sind und ob identify dein Konto angehängt hat, falls du es eingerichtet hast. Die ganze Prüfung dauert zwei Minuten, und es ist genau das, was deine Nutzenden erleben werden.

Von hier aus landen Berichte auf einem Kanban-Board, gehen über Integrationen an deinen Team-Chat oder Issue-Tracker und werden, wenn du den MCP-Server verbindest, zu etwas, das dein KI-Coding-Assistent direkt untersuchen kann.