Von Christian Wilms · 5. Juni 2026 · aktualisiert am 15. Oktober 2026
Ein typisches Szenario. Donnerstagvormittag, Anruf aus dem Lager: “Warum kommen keine neuen Aufträge mehr rein?” Ein Blick in den Shop zeigt das Gegenteil von Ruhe. Bestellungen laufen normal auf, Montag, Dienstag, Mittwoch, alles da. Nur in der Warenwirtschaft fehlen sie. Drei Tage lang hat der Flow, der Bestellungen vom Shop ins ERP überträgt, schlicht nichts übertragen. Keine Fehlermeldung im Shop, keine im ERP, kein Hinweis im Tagesgeschäft. Der Flow war einfach aus.
Das Muster ist beim großen Händler dasselbe wie beim kleinen B2B-Shop: Eine Klick-Automatisierung in Zapier, Make oder einem vergleichbaren Tool verbindet Shop und Warenwirtschaft. Sie funktioniert monatelang. Und dann stirbt sie still.
Klick-Automatisierungen sind Fire-and-forget. Der Flow wird einmal eingerichtet, läuft im Hintergrund, und solange er läuft, denkt niemand mehr an ihn. Genau darin liegt das Risiko: In den meisten Setups gibt es niemanden und nichts, dessen Aufgabe es ist zu bemerken, dass er nicht mehr läuft.
Die Tools melden sich durchaus. Aber wohin? Typischerweise per Mail an das Konto, mit dem der Flow vor zwei Jahren angelegt wurde. Das ist gern die Adresse einer Agentur, eines ehemaligen Mitarbeiters oder ein Sammelpostfach, das niemand liest. Die Mail “Your Zap was turned off” ist dann technisch korrekt zugestellt und faktisch unsichtbar.
Dazu kommt ein psychologischer Effekt: Das Ausbleiben von Daten sieht im Tagesgeschäft lange wie Ruhe aus. Keine neuen Aufträge in der Warenwirtschaft kann auch ein schwacher Verkaufstag sein. Erst wenn die Lücke groß genug ist, fällt sie auf. Im Beispiel vom Anfang sind das drei Tage und mehrere Dutzend Bestellungen, die von Hand nacherfasst werden müssen, inklusive der unangenehmen Frage, welche davon schon halb im ERP gelandet sind.
Wenn ein Schritt im Flow wiederholt fehlschlägt, etwa weil die ERP-Schnittstelle zehn Minuten nicht erreichbar war, pausieren viele Tools den kompletten Flow oder schalten ihn nach einer Fehlerserie ganz ab. Aus einem vorübergehenden Problem (Wartungsfenster, Neustart, kurzer Netzwerkfehler) wird damit ein dauerhaftes: Der Flow bleibt aus, bis ihn jemand von Hand wieder aktiviert. Ein zehnminütiger Ausfall der Gegenseite kostet so drei Tage Synchronisation.
Shop-APIs und ERP-Schnittstellen drosseln Anfragen. Wer zu viele Requests in zu kurzer Zeit schickt, bekommt HTTP 429 zurück. Ein sauber gebauter Client wartet dann und versucht es später erneut. Klick-Tools behandeln das oft wie einen normalen Fehler: Der Task gilt als fehlgeschlagen, der Datensatz ist weg. Besonders tückisch wird das bei Lastspitzen, also genau dann, wenn viele Bestellungen reinkommen und der Sync am wichtigsten wäre.
Bricht ein Lauf in der Mitte ab, stellt sich die Frage: Was wurde schon übertragen? Ohne Idempotenz, also ohne die Eigenschaft, dass dieselbe Operation beliebig oft ausgeführt werden kann, ohne den Zustand erneut zu verändern, gibt es nur zwei schlechte Antworten. Entweder man überträgt alles noch einmal und produziert doppelte Aufträge im ERP. Oder man lässt es und riskiert Lücken. Klick-Flows haben dieses Konzept in der Regel schlicht nicht, weil jeder Trigger ein Einzelereignis ist und niemand Buch führt.
Selbst wenn das Tool jeden Fehler protokolliert: Ein Log, das niemand abonniert hat, ist Dekoration. Die Fehlerhistorie liegt im Dashboard des Anbieters, hinter einem Login, den im Zweifel nur eine Person hat. Es gibt keinen Alarm, der aktiv eskaliert, wenn etwas über Stunden nicht funktioniert. Das ist der Kern des stillen Sterbens: Nicht der Fehler ist das Problem, sondern dass er keinen Empfänger hat.
Ein eigener Sync ist erst einmal unspektakulär: ein Skript oder ein kleiner Dienst auf einem Server, der regelmäßig läuft, Bestellungen abholt und an die Warenwirtschaft übergibt. Der Unterschied liegt nicht in der Grundfunktion, sondern in vier Eigenschaften, die man bei Klick-Tools nicht oder nur eingeschränkt bekommt.
Jeder Übertragungsschritt darf scheitern, ohne dass der Lauf stirbt. Schlägt ein Request fehl, wird er nach einer kurzen Wartezeit wiederholt, und die Wartezeit wächst mit jedem Versuch (Exponential Backoff). HTTP 429 und 5xx werden als das behandelt, was sie sind: vorübergehende Zustände. Erst wenn alle Versuche ausgeschöpft sind, landet der Datensatz in einer Dead-Letter-Queue, also einer Warteliste für manuell zu klärende Fälle. Der Rest des Laufs geht normal weiter.
Jede Bestellung bekommt einen eindeutigen Schlüssel, zum Beispiel die Shop-Bestellnummer. Die Gegenseite im ERP prüft vor dem Anlegen, ob dieser Schlüssel schon existiert. Damit kann derselbe Lauf gefahrlos wiederholt werden: Was schon da ist, wird übersprungen. Zusätzlich merkt sich der Sync einen Cursor, also den Zeitstempel der letzten erfolgreich verarbeiteten Bestellung. Nach einem Absturz setzt der nächste Lauf exakt dort auf. Keine Duplikate, keine Lücken.
Jeder Lauf schreibt nachvollziehbar mit, was er getan hat. So sieht das bei einem überwachten Bestell-Sync aus, hier ein vereinfachtes Beispiel:
03:15:02 [sync-orders] start run_id=20260608-031502
03:15:03 [sync-orders] 14 neue Bestellungen seit Cursor 2026-06-07T22:10:11Z
03:15:04 [sync-orders] Bestellung 100482 -> ERP ok (key=shop-100482)
03:15:05 [sync-orders] Bestellung 100483 -> ERP HTTP 429, Retry in 2s (Versuch 1/6)
03:15:08 [sync-orders] Bestellung 100483 -> ERP ok nach 2 Versuchen
03:16:40 [sync-orders] Bestellung 100517 FEHLGESCHLAGEN nach 6 Versuchen -> Dead-Letter
03:16:40 [alert] sync-orders: 1 Eintrag in Dead-Letter-Queue, Alarm gesendet
03:16:41 [sync-orders] fertig: 13 ok, 1 offen, Cursor=2026-06-08T03:14:55Z, Dauer 99sAn so einem Log lässt sich jede Frage beantworten, die im Schadensfall zählt: Was wurde wann übertragen, was hing, was fehlt noch. Die eine fehlgeschlagene Bestellung blockiert nicht die anderen dreizehn, und sie verschwindet auch nicht. Sie liegt benannt in der Dead-Letter-Queue und hat einen Alarm ausgelöst.
Der wichtigste Baustein ist gleichzeitig der einfachste. Klassische Alarme melden, wenn etwas Schlimmes passiert. Das reicht nicht, denn der gefährlichste Zustand ist der, in dem gar nichts mehr passiert. Deshalb dreht man die Logik um: Der Sync meldet sich nach jedem erfolgreichen Lauf aktiv beim Monitoring. Bleibt diese Meldung aus, schlägt das Monitoring Alarm. Das nennt sich Dead-Man-Switch und ist mit einer Zeile umgesetzt:
# Am Ende jedes erfolgreichen Laufs:
curl -fsS https://monitoring.example.com/ping/sync-orders
# Bleibt der Ping länger als 30 Minuten aus, alarmiert das Monitoring.Damit kann der Fall vom Anfang nicht mehr tagelang unbemerkt bleiben. Ein Sync, der nichts mehr tut, fällt nicht erst auf, wenn das Lager anruft, sondern nach einer halben Stunde, per Nachricht an einen Kanal, den tatsächlich jemand liest.
Nein. Für unkritische Komfort-Automatisierung sind Klick-Tools völlig in Ordnung: eine Slack-Nachricht bei neuem Formulareintrag, ein Eintrag in einer Tabelle, ein Newsletter-Abonnent im CRM. Wenn so etwas einen Tag ausfällt, ärgert es niemanden ernsthaft.
Die Grenze verläuft dort, wo Geld und Verbindlichkeiten durch die Leitung gehen: Bestellungen, Lagerbestände, Preise, Rechnungen. Alles, dessen Ausfall Sie erst nach Tagen bemerken würden und dessen Nacharbeit Handarbeit bedeutet, gehört in eine Integration, die Wiederholung, Idempotenz, Logging und einen Dead-Man-Switch mitbringt. Das ist keine Frage des Werkzeugstolzes, sondern der Frage, wer den Fehler bemerkt: Sie oder Ihr System.
Sie müssen dafür nichts neu bauen, um anzufangen. Stellen Sie Ihrem bestehenden Setup drei Fragen:
Wer alle drei Fragen sauber beantworten kann, hat einen überwachten Sync, egal mit welchem Werkzeug. Wer bei einer davon ins Schwimmen kommt, sollte das klären, bevor der nächste Anruf aus dem Lager kommt. Der Ausfall im Beispiel dauert drei Tage, nicht weil das Problem kompliziert ist, sondern weil niemand dafür zuständig ist, es zu bemerken. Diese Zuständigkeit ist der billigste Teil der ganzen Integration: ein Ping am Ende jedes Laufs und ein Monitoring, das sein Ausbleiben meldet. Was ich für solche Fälle baue, finden Sie unter individuelle Tools für Onlineshops.
Das Gegenmodell zur Klick-Kette ist eigener Code, den jeder nachlesen kann. Mein Dokumentenarchiv setzt auf Paperless-ngx auf: Eine eigene KI liest, benennt und verschlagwortet die Dokumente und ordnet Absender zu, mit lokalen Modellen und in Archiven mit über 290.000 Dokumenten. Der Code liegt öffentlich auf GitHub.
Aus der PraxisDokumentenarchiv
Was verlängert sich im März?
Zwei Verträge: Heizungswartung und Mobilfunk. Kündbar bis Ende Dezember.
Vereinfacht nachgestellt aus Systemen, die ich gebaut habe
Neues Projekt, Verbesserung oder einfach eine Frage: Ein paar Zeilen genügen. Sie bekommen eine ehrliche, kostenlose Einschätzung per Mail, ohne Telefonat und ohne Verkaufsgespräch.