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.
Dieses Muster habe ich in den letzten Jahren mehrfach gesehen, bei einem Händler mit knapp 2.000 Artikeln genauso wie bei einem 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.
Warum niemand etwas merkt
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. Bei dem Händler aus dem Beispiel waren es drei Tage und mehrere Dutzend Bestellungen, die manuell nacherfasst werden mussten, inklusive der unangenehmen Frage, welche davon schon halb im ERP gelandet waren.
Die typischen Failure-Modes von Klick-Automatisierungen
1. Abschalten statt Wiederholen
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.
2. Rate-Limits und Timeouts
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.
3. Keine Idempotenz: Duplikate und Lücken
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.
4. Fehler ohne Empfänger
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.
Was eine server-seitige Integration anders macht
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.
Retry mit Backoff
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.
Idempotenz und Cursor
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.
Logging, das man lesen kann
Jeder Lauf schreibt nachvollziehbar mit, was er getan hat. So sieht das bei einem überwachten Bestell-Sync aus, hier ein gekürztes, anonymisiertes 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.
Monitoring mit Dead-Man-Switch
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.
Sind Zapier und Make damit nutzlos?
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.
Fazit: Drei Fragen an Ihren aktuellen Sync
Sie müssen dafür nichts neu bauen, um anzufangen. Stellen Sie Ihrem bestehenden Setup drei Fragen:
- Wer erfährt es, wenn der Sync heute Nacht stehen bleibt? Wenn die Antwort “niemand” oder “ein Postfach, das keiner liest” lautet, haben Sie denselben Zustand wie der Händler vom Anfang, nur noch vor dem Vorfall.
- Was passiert mit einer Bestellung, deren Übertragung fehlschlägt? Wird sie wiederholt, geparkt und gemeldet, oder ist sie einfach weg?
- Können Sie einen Lauf gefahrlos wiederholen? Wenn ein erneuter Durchlauf Duplikate erzeugt, fehlt Idempotenz, und jede Störung wird zur Aufräumaktion.
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 vom Anfang hat drei Tage gedauert, nicht weil das Problem kompliziert war, sondern weil niemand dafür zuständig war, 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.