Was tun mit einem Fehlerbericht, den du nicht reproduzieren kannst

ReproduktionDenis Povarov30. August 2026

Der Bericht liegt in deinem Tracker. Die Person hat den Fehler gesehen, und du glaubst ihr, aber auf deinem Rechner funktioniert alles, und du hast schon eine Stunde damit verbracht, genau das zu beweisen. Und jetzt?

Die meisten Teams haben hier genau einen Zug: das Label „nicht reproduzierbar“ setzen und schließen. Dieser Zug kostet dich still und leise doppelt. Der Bug bleibt in Produktion, wo die nächsten Nutzenden ihn finden. Und die meldende Person lernt, dass es sinnlos ist, Bugs zu melden. Der nächste Bericht, der mit dem Detail, das diesen Fall geknackt hätte, wird nie geschrieben.

Herauszufinden, warum ein Bug bei der meldenden Person auftritt und bei dir nicht, ist eine eigene Disziplin: Der Unterschied steckt immer irgendwo in Zustand, Timing, Umgebung oder Daten. Hier geht es um die andere Hälfte der Arbeit, den Ablauf. Was du heute mit dem Ticket tatsächlich machst, wenn die Reproduktion gescheitert ist.

Ersetze „geschlossen“ durch eine echte Entscheidung

Ein nicht reproduzierbarer Bericht hat drei ehrliche Ausgänge, und „geschlossen“ gehört nicht dazu:

Trotzdem behoben: Die Belege zeigten auf eine Ursache, die du beheben konntest, ohne den Bug je live zu sehen.
Geparkt, mit Instrumentierung: Du hast ihn nicht geknackt, also hast du eine Falle für das nächste Auftreten gestellt und weitergemacht.
Unter Beobachtung: Der Bericht ist ein Datenpunkt, und du wartest bewusst auf einen zweiten.

Jeder der folgenden Schritte führt zu einem dieser drei Ausgänge. Das Ziel der Triage ist nicht die Reproduktion, sondern eine Entscheidung über das Ticket, die du begründen kannst.

Schritt 1: Hol alles aus dem Bericht, den du hast

Bevor du einen Browser anfasst, zieh alles heraus, was der Bericht tatsächlich enthält:

Prüf den Zeitstempel. Leg die Uhrzeit des Berichts neben deine Server-Logs und deine Deploy-Historie. „Um 14:02 ging es kaputt“ neben „Deploy um 13:58“ hat mehr Rätsel gelöst als jeder Debugger.
Such nach verwandten Berichten. Gleiche Seite, gleicher Fehlertext, gleicher Endpoint, in deinem Tracker und in deinem Error-Monitoring. Ein Bericht, der einzigartig aussieht, ist oft schon der dritte seiner Art unter drei verschiedenen Titeln.
Lies das Symptom rückwärts. Wenn der Button „nichts gemacht hat“, zähl auf, was einen Klick verschlucken kann: ein deaktivierter Zustand, ein frühes Return, eine unbehandelte Rejection. Jede Hypothese setzt einen Zustand voraus, in dem die Person gewesen sein könnte. Du reproduzierst noch nicht, du stellst eine Shortlist zusammen.

Schritt 2: Reproduziere wie die meldende Person, mit einer Stunde Timebox

Reproduktionsversuche scheitern, weil man sie aus der eigenen Lage heraus unternimmt: frische Session, schnelles Netz, Admin-Konto, großer Bildschirm. Nimm dir eine Stunde, und nur eine, in der du bewusst die meldende Person bist. Ihr Browser und ihre Geräteklasse, ihr Viewport, eine gedrosselte Verbindung, ein Konto mit ihrer Rolle und ihrer Datenmenge, ihre Abfolge von Aktionen statt der vernünftigen.

Bringt die Stunde nichts, hör auf. Auf unbegrenzten Reproduktionsjagden frisst ein mittelgroßer Bug einen ganzen Sprint. Das Playbook geht so oder so weiter.

Schritt 3: Stell der meldenden Person eine Frage, nicht fünf

Einen Fragebogen bricht man ab, eine einzelne konkrete Frage wird beantwortet. Such dir die aus, deren Antwort deine Shortlist halbiert („Passiert es nach dem Neuladen immer noch?“, „Passiert es jedes Mal beim selben Datensatz?“), und schick nur diese.

Noch eine Regel: Frag nach Fakten, nie nach Arbeit. „Welcher Browser?“ ist ein Fakt, den Nutzende nicht zuverlässig liefern können und den Tools automatisch erfassen. Wer danach fragt, verbraucht das Wohlwollen der meldenden Person für etwas, das ein Script-Tag hätte erledigen sollen.

Schritt 4: Park das Ticket richtig

Parken ist nicht Schließen. Ein richtig geparktes Ticket hat drei Dinge:

Die Belege angehängt: alles aus Schritt 1 plus die Hypothesen, die du ausgeschlossen hast, damit niemand nächsten Monat dieselbe Stunde noch einmal verbringt.
Eine gestellte Falle: die Log-Zeile, der Breadcrumb, die Assertion, die beim nächsten Auftreten anschlägt. Erfasst dein Tool für Fehlerberichte die Console-Ausgabe, macht ein gut platziertes console.error im verdächtigen Pfad aus dem nächsten Bericht die Diagnose.
Ein Auslöser für die Wiederkehr: Das Ticket öffnet sich wieder, sobald ein verwandter Bericht kommt, statt darauf zu bauen, dass sich jemand an das Ticket erinnert.

Schritt 5: Der zweite Bericht ist der Durchbruch

Nicht reproduzierbare Bugs kommen wieder, das ist das einzig Verlässliche an ihnen. Und der zweite Bericht verändert alles: Ein Bericht ist eine Anekdote, zwei sind ein Vergleich, fünf sind ein Datensatz. Frag, was die Vorkommen gemeinsam haben (Browser? Rolle? ein bestimmter Datensatz? Tageszeit?) und was nicht. Die gemeinsamen Variablen sind deine Ursache, der Rest ist Rauschen.

Deshalb sollten sich doppelte Berichte bei einer einzigen Aufgabe sammeln, statt als Duplikate geschlossen zu werden: Bei genau dieser Art von Bug ist der Stapel die Analyse. Hier hilft auch ein KI-Assistent wirklich. Über den MCP-Server von BugDump mit deinen Berichten verbunden, blättern Claude Code oder Cursor durch jeden Bericht einer Aufgabe und finden den roten Faden schneller als ein Mensch, der fünf Session-Replays durchspult.

Halte die meldende Person auf dem Laufenden

Zwei Sätze, zu zwei Zeitpunkten: wenn du das Ticket parkst („Wir konnten das noch nicht eingrenzen. Wir haben Monitoring ergänzt und Ihren Bericht offen gelassen.“) und wenn der Bug behoben ist („Ihr Bericht vom März hat den Fall gelöst, danke.“). Der erste Satz erhält die Beziehung, der zweite ist die billigste Investition in eine gute Meldekultur, die es gibt. Wer sieht, dass die eigenen Berichte etwas bewirken, schreibt bessere.

Repariere die Pipeline, nicht nur den Bug

Alles, worum dieses Playbook herumarbeitet (fehlende Umgebung, fehlende Abfolge, fehlende Fehler), war im Moment des Fehlers im Browser der meldenden Person vorhanden. Es wurde nur nicht erfasst. Das ist die dauerhafte Lösung: Ein Bericht, der über BugDump gemeldet wird, kommt mit dem Console-Puffer (Fehler markiert), den letzten Netzwerk-Requests (Fehlschläge hervorgehoben), Browser, Betriebssystem, Gerät, Viewport, URL der Seite und einem Session-Replay zum Durchspulen, das zeigt, was die Person tatsächlich getan hat. Ergänze einen identify-Aufruf, und du weißt, welches Konto du dir ansehen musst, statt eines zu erraten, das ihm ähnelt.

Mit dieser Pipeline wird der Großteil dieses Playbooks überflüssig: Schritt 1 ist schon erledigt, Schritt 2 beginnt mit Fakten, und die Frage aus Schritt 3 ist meist schon beantwortet. „Nicht reproduzierbar“ verschwindet nicht ganz, hört aber auf, ein Abschluss zu sein, und wird zu dem, was es von Anfang an hätte sein sollen: ein seltener, vorübergehender Zustand zwischen Bericht und Fix.