Wenn zwei Automatisierungen sich gegenseitig triggern: die Endlosschleife, die am Wochenende zuschlägt
Zwei harmlose Workflows, ein leeres Konto am Montag. Wie Trigger-Loops zwischen Automatisierungen entstehen, warum sie im Test unsichtbar bleiben und mit welchen vier Mustern Sie sie in Make, n8n und Zapier verhindern.
40.000 Operationen an einem Wochenende, an dem niemand im Büro war
Der Anruf kam an einem Montagmorgen. Über das Wochenende hatte ein Kunde sein komplettes Monatskontingent bei Make verbraucht, rund 40.000 Operationen, und das Konto stand still. Niemand war im Büro gewesen. Niemand hatte einen Knopf gedrückt. Trotzdem hatten zwei Szenarien zwei Tage lang durchgearbeitet und sich gegenseitig immer weiter angefeuert.
Der Hergang war simpel, und genau das macht ihn so gefährlich. Szenario A reagierte auf jede Änderung im CRM und schrieb den aktuellen Stand in eine zentrale Tabelle. Szenario B beobachtete diese Tabelle und schrieb jede Änderung zurück ins CRM. Beide für sich genommen völlig harmlos. Solange nur ein Mensch hin und wieder einen Datensatz anfasste, fiel nichts auf. Doch als A zum ersten Mal automatisch in die Tabelle schrieb, weckte das B. B schrieb zurück ins CRM, das weckte wieder A. Ab da lief die Schleife allein, ohne Pause, bis das Kontingent leer war.
Diese Art von Endlosschleife sehen wir regelmäßig. Sie hat eine besonders unangenehme Eigenschaft: Im Test taucht sie fast nie auf.
Warum die Schleife im Test unsichtbar bleibt
Wenn Sie Szenario A bauen und testen, ist B oft noch gar nicht aktiv. Oder umgekehrt. Sie prüfen jede Automatisierung für sich, sehen einen sauberen Durchlauf und haken sie ab. Die Schleife entsteht aber erst im Zusammenspiel, und sie braucht einen Auslöser, den im Test selten jemand erzeugt: eine echte automatische Schreiboperation.
Dazu kommt die Menge. Beim manuellen Test ändern Sie einen Datensatz, schauen, ob er ankommt, fertig. Ein einzelner Durchlauf schaukelt sich nicht hoch, weil Sie nach dem ersten Hin und Her aufhören. Die Maschine hört nicht auf. Sie macht weiter. Also wartet die Schleife auf genau die Bedingungen, die Ihr Test nie herstellt: beide Seiten aktiv, eine automatische Schreiboperation und niemand, der die zweite Runde bemerkt. Genau deshalb passiert es am Wochenende, nachts, im Urlaub. Die Ruhe ist kein Zufall. Die Ruhe ist der Auslöser.
Das Grundmuster: Jeder Schreibvorgang ist auch ein Trigger
Der Kern des Problems steckt in einer Annahme, die fast niemand bewusst trifft: dass ein Schreibvorgang der eigenen Automatisierung etwas anderes ist als ein Klick durch einen Menschen. Für die meisten Systeme ist er das nicht. Ein "Datensatz aktualisiert"-Event unterscheidet nicht, wer aktualisiert hat. Ein Update ist ein Update.
Sobald zwei Automatisierungen denselben Datenbestand lesen und schreiben, haben Sie einen Kreis gebaut, ob Sie wollten oder nicht. A schreibt, B hört zu. B schreibt, A hört zu. Die einzige echte Frage ist, was den Kreis unterbricht. Lautet Ihre ehrliche Antwort "es wird schon jemand merken", dann haben Sie keine Sicherung, sondern nur eine Verzögerung vor demselben Ergebnis.
Vier Muster, mit denen wir Trigger-Loops verhindern
Wir bauen solche Konstellationen heute nur noch mit mindestens einer dieser Sicherungen. Bei kritischen Strecken mit zweien.
Die zuverlässigste ist, die Herkunft jeder Änderung zu markieren. Wenn eine Automatisierung schreibt, hinterlässt sie eine Spur, ein Feld wie "letzte Änderung durch: System" oder einen Zeitstempel, den nur sie setzt. Die jeweils andere Seite prüft am Anfang, woher die Änderung stammt, und bricht ab, sobald sie vom Gegenstück kommt. Diese Methode greift die Ursache an, nicht das Symptom, und deshalb mag ich sie am liebsten.
Fast genauso wichtig ist, nur dann zu schreiben, wenn sich wirklich etwas geändert hat. Viele Schleifen leben einzig davon, dass eine Automatisierung schreibt, obwohl alles längst stimmt. Sie überträgt "Status: offen", obwohl drüben schon "Status: offen" steht. Das System feuert trotzdem ein Update-Event, und die Schleife dreht sich weiter. Vergleichen Sie vor jedem Schreibvorgang den alten gegen den neuen Wert. Sind sie gleich, schreiben Sie nicht. Allein das nimmt vielen Loops die Energie.
Die sauberste Lösung ist, pro Feld nur eine schreibende Richtung zuzulassen. Legen Sie fest, welches System für welches Feld die Wahrheit hält. Der Preis kommt aus dem Shop, also schreibt nur der Shop den Preis, nie das CRM. Der Vertriebsstatus lebt im CRM, also fasst der Shop ihn nicht an. Hat jedes Feld genau einen Besitzer, kann kein Kreis entstehen, weil nie zwei Seiten um denselben Wert ringen. Echte bidirektionale Synchronisation, bei der beide Seiten alles schreiben dürfen, ist in den meisten Fällen ein Designfehler und kein Feature.
Und selbst mit all dem will ich eine Notbremse haben, die greift, wenn ich etwas übersehen habe. Ein simpler Zähler reicht oft: Läuft dieselbe Strecke mehr als, sagen wir, fünfzig Mal in fünf Minuten, schaltet sie sich selbst ab und schickt eine Nachricht. Lieber ein Fehlalarm zu viel als ein leeres Konto am Montag. Diese Bremse ersetzt keine der anderen drei Sicherungen. Sie ist nur das Netz darunter.
Wie das konkret in den Tools aussieht
In Make führt der schnellste Weg über ein zusätzliches Feld und einen Filter direkt hinter dem Trigger. Sie setzen beim Schreiben ein Feld "geändert von" auf den Namen des Szenarios und bauen am Anfang des Gegenstücks einen Filter ein, der abbricht, sobald dort der Name der anderen Seite steht. Make zählt jeden abgebrochenen Durchlauf zwar als Operation, aber eine Operation ist deutlich billiger als vierzigtausend.
In n8n haben Sie mehr Freiheit, weil Sie in einem Function- oder IF-Node beliebig vergleichen können. Wir lesen dort den alten Datensatz, vergleichen Feld für Feld und lassen den Workflow früh enden, wenn sich nichts Relevantes geändert hat. Wenn Sie n8n selbst hosten, frisst ein leerlaufender Loop nicht Ihr Operationskontingent, sondern Ihre CPU. Das Konto steht dann nicht still, aber der Server geht in die Knie, und die Symptome sind schwerer zu deuten.
In Zapier ist die Lage am unbequemsten, weil die Logik eines Zaps bewusst einfach gehalten ist. Hier hilft am ehesten ein Filterschritt, dazu die eingebaute Schutzfunktion, die einen Zap pausiert, wenn er sich auffällig oft selbst auslöst. Verlassen Sie sich nicht allein darauf. Diese Funktion ist ein Notnagel und kein Ersatz für sauberes Design.
Wenn die Schleife schon läuft
Falls Sie das hier lesen, weil es bei Ihnen gerade dreht: erst stoppen, dann verstehen. Schalten Sie eines der beiden beteiligten Szenarien ab, egal welches. Damit ist der Kreis unterbrochen, und Sie kaufen sich Zeit. Erst danach klären Sie, welche Daten in der Zwischenzeit Schaden genommen haben.
Und meistens hat etwas Schaden genommen. Wir hatten den Fall, dass ein Zeitstempelfeld bei jedem Durchlauf einen Hauch verändert wurde und nach ein paar tausend Runden Werte enthielt, die nie ein Mensch eingetragen hatte. Sehen Sie sich die betroffenen Datensätze einzeln an, bevor Sie die Automatisierungen wieder scharf schalten. Ein Backup von vor dem Wochenende ist hier viel wert, und es ist einer der Gründe, warum wir bei kritischen Strecken auf eine Versionierung der Daten bestehen.
Was am Ende bleibt
Trigger-Loops sind kein exotisches Phänomen, das nur Anfängern passiert. Sie entstehen aus einer der häufigsten Anforderungen überhaupt, "halte mir diese beiden Systeme synchron", und aus einer Annahme, die in dem Moment, in dem man sie ausspricht, sofort falsch klingt: dass die eigenen Automatisierungen schon wissen, wann sie aufhören müssen. Tun sie nicht. Sie tun, was man ihnen gesagt hat, und zwar so lange, bis etwas anderes sie stoppt.
Deshalb gehört zu jeder Konstellation, in der zwei Automatisierungen denselben Datenbestand anfassen, von Anfang an eine Frage: Was unterbricht den Kreis? Wenn Sie darauf keine technische Antwort haben, sondern nur die Hoffnung, dass schon jemand rechtzeitig auf das richtige Dashboard schaut, dann ist die Frage nicht beantwortet. Sie ist nur vertagt, meistens auf ein Wochenende.