Was ist BugDump? Fehlerberichte für Websites mit einem Script-Tag

ProduktDenis Povarov30. August 2026

BugDump ist ein Widget für Fehlerberichte auf Websites. Du fügst ein Script-Tag ein, in der Ecke deiner App erscheint ein schwebender Bug-Button, und ab diesem Moment können alle, die deine App nutzen, Fehlerberichte schicken, die mit dem Kontext ankommen, den du zum Beheben wirklich brauchst: Console-Logs, Netzwerkanfragen, ein Session-Replay, Details zur Umgebung und ein annotierter Screenshot.

Hier steht, was BugDump macht, wie ein Bericht aussieht und wo es in deinen Workflow passt.

Welches Problem es löst

Die meisten Fehlerberichte aus dem echten Leben sehen so aus: „Die Seite funktioniert nicht.“ Keine URL, keine Browserversion, keine Schritte, keine Fehlermeldung. Du antwortest und fragst nach Details, die Person ist längst weitergezogen, und der Bug bleibt liegen, bis jemand aus deinem eigenen Team zufällig darüber stolpert.

Die Informationen, die du gebraucht hättest, gab es in dem Moment, als der Bug auftrat: in der Console, im Netzwerk-Tab, im DOM. Sie wurden nur nicht erfasst. Die Aufgabe von BugDump ist, sie automatisch zu erfassen, damit aus einer einzeiligen Beschwerde eine vollständige Fallakte wird.

So funktioniert die Einrichtung

Die Installation ist eine einzige Zeile HTML:

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

Das Skript initialisiert sich selbst über das Attribut data-api-key: keine SDK-Aufrufe, kein Build-Schritt, keine Anforderungen an das Framework. Es funktioniert mit React, Vue oder reinem JavaScript, weil es deinen Anwendungscode gar nicht anfasst. Wenn dir eine gebündelte Abhängigkeit lieber ist, gibt es ein npm-Paket (@bugdump/sdk) mit vollständigen TypeScript-Typen und einen manuellen Init-Modus für die Steuerung im Code.

Das Widget rendert in einem Shadow DOM, also sickern seine Styles nie in deine App, und dein CSS macht das Widget nie kaputt. Du kannst das Theme festlegen (hell, dunkel oder wie im Betriebssystem), das Icon des Auslösers ändern, den Button verschieben oder ganz ausblenden und jeden Text der Oberfläche überschreiben. Das hilft, wenn dein Produkt nicht auf Englisch ist.

Was in einem Bericht steckt

Wenn jemand auf den Bug-Button klickt, das Problem beschreibt und auf Senden drückt, enthält der Bericht in deinem Dashboard automatisch:

Console-Logs: die letzten 300 Einträge (2.000 während einer Aufnahme), Fehler und Warnungen hervorgehoben, durchsuchbar.
Netzwerkanfragen: die letzten 150 Anfragen (1.000 während einer Aufnahme) mit Statuscodes; fehlgeschlagene Anfragen sind markiert. Request- und Response-Bodys kommen mit, wenn du das einschaltest.
Session-Replay: DOM-Snapshots auf Basis von rrweb, die zeigen, was vor dem Bug passiert ist, durchspulbar wie ein Video.
Umgebung: Browser, Betriebssystem, Gerät, Bildschirmgröße, Viewport und die URL der Seite.
Performance-Metriken: TTFB, FCP, Zeit bis DOM-ready, Ladezeit und Nutzung des JS-Heaps.

Zusätzlich zum automatischen Kontext lassen sich ein Screenshot (mit Werkzeugen zum Annotieren: Pfeile, Rechtecke, Freihandzeichnen, Text und Weichzeichner, um sensible Daten zu verbergen), eine Bildschirmaufnahme, eine Sprachnotiz oder Dateien anhängen. Nichts davon ist Pflicht. Der kleinste brauchbare Bericht ist ein Satz und ein Klick, und die Telemetrie kommt trotzdem mit.

Wenn sich Leute in deiner App anmelden, hängt bugdump('identify', { email }) die Identität der meldenden Person an. So weißt du, wer auf das Problem gestoßen ist, ohne dass jemand die eigene E-Mail-Adresse eintippen muss.

Vom Bericht zum Fix

Berichte landen in einem Dashboard und werden dort zu Aufgaben auf einem Kanban-Board. Von da aus geht es so weiter:

Integrationen leiten Bugs an die Tools weiter, die du schon nutzt: Telegram, Slack, Discord, GitHub Issues, Jira, Asana und weitere in den bezahlten Plänen. Im Free-Plan erreichen dich neue Berichte per E-Mail und in der App.
Der MCP-Server verbindet dein Projekt mit Claude Code, Cursor oder jedem anderen MCP-fähigen Client. So liest ein KI-Assistent den vollständigen Kontext eines Bugs, also Berichte, Console, Netzwerk und Screenshots, und untersucht ihn in natürlicher Sprache.
Ein öffentliches Portal (optional) zeigt den Leuten, die Bugs melden, ihre Berichte, und daneben kannst du eine Roadmap und einen Changelog veröffentlichen.

Was es kostet

Der Preis richtet sich danach, wie viele Berichte du sammelst, nicht nach Seats, und es gibt keinen Tarif mit „Vertrieb kontaktieren“.

Free: 0 $, für immer. 500 Berichte pro Monat und Projekt, 1 GB Speicher, 3 Projekte, E-Mail-Benachrichtigungen, der MCP-Server für Claude Code und die komplette Erfassung (Screenshot, Replay, Console, Netzwerk).
Pro: 4,99 $ pro Monat. 10.000 Berichte pro Monat und Projekt, 10 GB Speicher, 20 Projekte, alle Integrationen, Webhooks und die Möglichkeit, das BugDump-Branding aus dem Widget zu entfernen.
Ultra: 9,99 $ pro Monat. 100.000 Berichte pro Monat und Projekt, 50 GB Speicher, 100 Projekte und die höchsten Rate-Limits. Gedacht für Produkte mit viel Traffic und für Agenturen, die viele Websites für ihre Kundschaft betreuen.

Preise zzgl. Steuern; Paddle, über das die Abrechnung läuft, schlägt fällige Steuern beim Checkout auf. Für den Free-Plan brauchst du keine Kreditkarte. Du kannst also den ganzen Ablauf mit Widget, Bericht und Dashboard testen, bevor du etwas bezahlst.

Für wen es gedacht ist

BugDump ist bewusst auf kleine Teams ausgelegt. Wenn du ein Nebenprojekt, ein Indie-SaaS oder ein kleines Produktteam hast, willst du wahrscheinlich keinen schwergewichtigen Issue-Tracker einrichten, nur um von kaputten Buttons zu erfahren. Ein Script-Tag und ein Kanban-Board sind das ganze System.

Es passt auch zu Agenturen und Teams mit Betaprogrammen: Leute ohne technischen Hintergrund sehen nie ein Formular, das nach „Browserversion“ oder „Schritten zur Reproduktion“ fragt. Sie klicken auf einen Button und schreiben einen Satz, und das Widget sammelt die technische Hälfte des Berichts für sie ein.

So fängst du an

Leg ein kostenloses Konto an, erstelle ein Projekt und füg das Script-Tag in deine Website ein. Der Button erscheint sofort, und der erste Bericht, den du dir selbst schickst, zeigt dir am schnellsten, wie die Berichte aussehen werden, die bei dir ankommen. Wenn du tiefer einsteigen willst: Das SDK unterstützt Feature-Toggles, Filter gegen das Rauschen gesprächiger Drittanbieter-Skripte, eigene Übersetzungen und Steuerung im Code. Die Standardkonfiguration ist aber so gebaut, dass die meisten Websites sie unverändert ausliefern.