60.000 Fehler an einem Tag: Wie ein einzelner Ausfall zum Fehler-Sturm wird – und wie man ihn verhindert

Ein Ausfall, 60.000 Fehlermeldungen

Anfang Juli 2026 war das Marketing-System der internationalen Weinplattform VINUM nicht erreichbar. Die Ursache lag weder bei uns noch beim Marketing-System selbst: Ein DNS-Problem auf Ebene der Domain sorgte dafür, dass sich die Adresse des Dienstes schlicht nicht mehr auflösen ließ. Solche Ausfälle passieren – bei Drittanbietern, bei Domains, bei Rechenzentren. Interessant ist, was die eigene Website in dieser Zeit tut.

Bei VINUM tat sie etwas sehr Fleißiges und sehr Sinnloses: Sie versuchte es immer wieder. Der Abgleich, der Adress- und Kontodaten aus TYPO3 an das Marketing-System Mautic überträgt, schickte bei jedem Lauf jeden geänderten Datensatz einzeln los, scheiterte bei jedem einzeln, schrieb für jeden eine Fehlermeldung ins Protokoll – und begann beim nächsten Lauf von vorn. Allein am 1. Juli standen so 60.174 identische Fehlermeldungen in einer 36 MB großen Protokolldatei. Am Tag davor waren es 23.

Der Ausfall eines Drittsystems darf nie zu tausendfacher Last im eigenen System werden.

Den Anlass haben wir genutzt, um alle Schreibwege von der Website zum Marketing-System durchzugehen – zumal ein Umzug und ein Upgrade des Marketing-Systems mit kurzen Wartungsfenstern anstanden. Dieser Beitrag zeigt, was wir gefunden und wie wir es gelöst haben.

Die Herausforderung

• Kein Gedächtnis für Ausfälle. Jeder Datensatz wurde einzeln übertragen, jeder Fehler einzeln behandelt. Dass nicht ein Datensatz, sondern der ganze Dienst weg war, konnte der Abgleich nicht erkennen.
• Schnelles Scheitern als Brandbeschleuniger. Eine nicht auflösbare Adresse scheitert in Millisekunden. Statt zu bremsen, liefen so Tausende Versuche pro Durchgang durch – und der Zeitplan startete gleich den nächsten.
• Ein ungepufferter Schreibweg. Newsletter-An- und -Abmeldungen gingen als direkte Anfrage an das Marketing-System – ohne Zeitlimit. War es nicht erreichbar, hing das Formular, und die Anmeldung ging verloren.
• Fehlerseite im Kundenkonto. Die Newsletter-Verwaltung im Kundenkonto fragte den Status live beim Marketing-System ab und zeigte bei einem Ausfall eine Fehlerseite statt der Kontoseite.
• Echte Fehler im Rauschen. Zwischen 60.000 gleichen Zeilen geht jeder andere Hinweis im Produktionsprotokoll unter.

Unsere Lösung

1. Den Unterschied erkennen: Datensatz abgelehnt oder Dienst weg?

Die Grundlage für alles Weitere ist eine Unterscheidung, die vorher fehlte. Lehnt das Marketing-System einen einzelnen Datensatz ab – etwa wegen einer ungültigen Angabe –, dann hat es geantwortet; das Problem liegt bei diesem einen Datensatz. Lässt sich die Adresse dagegen nicht auflösen, wird die Verbindung verweigert, läuft sie in ein Zeitlimit oder scheitert schon der verschlüsselte Verbindungsaufbau, dann ist der Dienst als Ganzes nicht erreichbar. Jede Anfrage an das Marketing-System meldet jetzt, in welche der beiden Kategorien ein Fehler fällt.

2. Der Circuit-Breaker: einmal scheitern, dann aufhören

Auf dieser Unterscheidung sitzt ein sogenannter Circuit-Breaker – das Software-Gegenstück zur Sicherung im Stromkasten:

1. Beim ersten Fehler der Kategorie „Dienst nicht erreichbar“ bricht der Abgleich den laufenden Durchgang ab.
2. Statt einer Meldung pro Datensatz schreibt er eine Zusammenfassung: Dienst nicht erreichbar, so viele Datensätze übersprungen.
3. Für fünf Minuten merkt sich das System den Ausfall. Folgeläufe in dieser Zeit versuchen es gar nicht erst und hinterlassen nur eine kurze Notiz.
4. Danach hebt sich die Pause von selbst auf, und der nächste Durchgang prüft erneut. Ist der Dienst zurück, läuft der Abgleich ohne manuellen Eingriff weiter.

Wichtig ist, was dabei nicht passiert: Übersprungene Datensätze werden nicht als übertragen markiert. Sie bleiben in der Warteschlange und werden nach der Störung vollständig nachgeholt – auf allen drei Abgleichswegen, auch auf dem, der fehlgeschlagene Datensätze bisher trotzdem als erledigt verbucht hätte. Lehnt das Marketing-System dagegen nur einen einzelnen Datensatz ab, bleibt alles wie gehabt: Dieser eine wird übersprungen, der Rest läuft weiter.

• 60.174 Fehlermeldungen an einem Tag – vorher
• 2 Protokollzeilen pro Durchgang während eines Ausfalls – nachher
• 5 Min. Pause, die sich von selbst aufhebt

Eine Kehrseite haben wir bewusst in Kauf genommen: Auch eine einzelne, ungewöhnlich langsame Antwort zählt als Zeitüberschreitung und kann den Abgleich für fünf Minuten pausieren. Weil sich die Pause selbst aufhebt und dabei keine Daten verloren gehen, ist das ein fairer Preis für den Schutz vor dem nächsten Fehler-Sturm.

3. Anmeldungen puffern statt „abschicken und hoffen“

Der heikelste Schreibweg war die Newsletter-Anmeldung. Sie lief nach dem Prinzip „fire and forget“: Die Website schickte die Anmeldung direkt an das Marketing-System und ging davon aus, dass sie ankommt. Ging das schief, bemerkte es niemand.

Jetzt speichert die Website jede An- und Abmeldung zuerst in einer eigenen Warteschlange in ihrer Datenbank und antwortet sofort. Eine Hintergrundaufgabe überträgt die Einträge im Minutentakt:

• Echte Erfolgskontrolle. Als erledigt gilt ein Eintrag nur, wenn das Marketing-System die Anmeldung tatsächlich angenommen hat. Verbindungsfehler, Zeitüberschreitungen und Serverfehler führen zu einem neuen Versuch beim nächsten Durchgang.
• Begrenzte Versuche. Nach zehn erfolglosen Versuchen wird ein Eintrag mit Fehlermeldung protokolliert und aussortiert, damit ein dauerhaft ungültiger Datensatz nicht jede Minute erneut durchläuft.
• Spur statt Löschen. Erfolgreich übertragene Einträge werden zunächst nur als erledigt markiert. Eine tägliche Aufräumaufgabe entfernt sie nach 30 Tagen endgültig – bis dahin lässt sich nachvollziehen, was wann übertragen wurde. Dasselbe gilt jetzt auch für die übrigen Übertragungen, etwa aus Gewinnspielen, Veranstaltungen und Bestellungen, die schon vorher gepuffert waren.

Für die Person, die sich anmeldet, ändert sich nur eines: Die Bestätigungsmail für das Double-Opt-In kommt nicht mehr sofort, sondern in der Regel innerhalb einer Minute. Wie diese Bestätigungsstrecke bei VINUM aufgebaut ist, beschreibt unser Beitrag zum Double-Opt-In mit Mautic.

4. Zeitlimits sind Pflicht

Ein Detail verdient einen eigenen Abschnitt, weil es so häufig fehlt: Die alte Anmeldung schickte ihre Anfrage ohne Zeitlimit. Antwortet die Gegenseite nicht, wartet eine solche Anfrage im ungünstigsten Fall, bis der Webserver selbst aufgibt – und blockiert so lange einen Prozess, der eigentlich Besucher bedienen sollte. Kommen viele Anfragen gleichzeitig, reicht ein einziger hängender Dienst, um die eigene Website auszubremsen.

Jede Verbindung zum Marketing-System hat jetzt zwei feste Grenzen: zehn Sekunden für den Verbindungsaufbau, 30 Sekunden für die gesamte Anfrage. Und weil die Anmeldungen ohnehin nicht mehr während des Seitenaufrufs übertragen werden, sondern im Hintergrund, spüren Besucher auch diese Wartezeit nicht mehr.

5. Lesen ohne Absturz

Auch lesende Zugriffe brauchen einen Plan B. Die Newsletter-Verwaltung im Kundenkonto fragt beim Marketing-System ab, welche Newsletter jemand abonniert hat. Kam keine Antwort, lief die Seite auf einen Programmfehler und zeigte eine Fehlerseite. Jetzt wertet sie eine fehlende Antwort als „Status gerade unbekannt“ – das Kundenkonto bleibt auch während einer Störung normal nutzbar.

6. Wiederkehrende Fehler gezielt abstellen

Aufgefallen ist die Fehler-Lawine in einer wöchentlichen Auswertung des Produktionsprotokolls – derselben Auswertung, die auch die leisen Probleme findet. Ein Beispiel aus derselben Woche: Im Verwaltungsbereich des Weinguides führte ein bestimmter Link dreimal innerhalb von sieben Tagen zu einem Serverfehler (HTTP 500). Die Ursache: Hatte ein Wein kein zugeordnetes Weingut, erzeugte die Seite trotzdem einen Link auf das Weingut – mit einer leeren Referenz, an der die Detailansicht scheiterte.

Behoben haben wir das an zwei Stellen. Der Link erscheint nur noch, wenn tatsächlich ein Weingut zugeordnet ist. Und die Detailansicht beantwortet eine leere Referenz – etwa über einen alten, irgendwo gespeicherten Link – mit einem sauberen „nicht gefunden“ (404) statt mit einem Absturz. Ein kleiner Fehler, aber genau die Art von Signal, die in einem Protokoll mit 60.000 Zeilen Rauschen niemand mehr sieht.

Das Ergebnis

• Kein Fehler-Sturm mehr: Fällt das Marketing-System aus, entstehen pro Durchgang zwei Protokollzeilen statt einer pro Datensatz.
• Automatische Wiederaufnahme: Nach einer Störung läuft der Abgleich ohne manuellen Eingriff weiter, übersprungene Datensätze werden nachgeholt.
• Keine verlorenen Anmeldungen: Newsletter-An- und -Abmeldungen werden gepuffert und übertragen, sobald der Dienst wieder erreichbar ist.
• Kein hängendes Formular: Anmeldungen warten nicht mehr auf das Marketing-System, und jede Verbindung hat ein festes Zeitlimit.
• Kundenkonto bleibt nutzbar, auch wenn das Marketing-System gerade nicht antwortet.
• Vorbereitet auf Wartungsfenster: Umzug und Upgrade des Marketing-Systems lassen sich planen, ohne Anmeldungen zu verlieren.
• Lesbares Protokoll: Echte Fehler wie der 500er im Weinguide fallen wieder auf – und werden abgestellt.

Fazit

Jede Anbindung an einen externen Dienst – CRM, Newsletter, Zahlungsanbieter – ist eine Abhängigkeit, die irgendwann ausfällt. Entscheidend ist nicht, ob das passiert, sondern was die eigene Website dann tut. Die Grundregeln sind unspektakulär: Jede Verbindung bekommt ein Zeitlimit, Schreibvorgänge werden gepuffert statt einfach abgeschickt, und wer merkt, dass die Gegenseite weg ist, hört auf zu klopfen und versucht es später wieder.