Infinite loops in automation: when two workflows keep triggering each other

The weekend two robots argued with each other

Most automation disasters announce themselves. Something turns red, an email bounces, a customer calls. This one did the opposite. It ran perfectly, thousands of times, all weekend, and that was exactly the problem.

A client of ours burned through their entire monthly operations budget between Friday night and Monday morning. Nobody was in the office. Nobody touched a thing. Two scenarios had spent the weekend triggering each other, around and around, until the account ran out of room to run.

The setup was almost boring. Scenario A watched the CRM and copied every change into a central table. Scenario B watched that table and copied every change back into the CRM. On their own, both were fine. The trouble started the first time A wrote to the table by itself. That woke B. B wrote back to the CRM, which woke A again. From there it ran on its own, no pause, no brakes, until the meter hit zero.

Why your tests never catch it

Here is the uncomfortable part. You can test both scenarios carefully and still miss this completely.

When you build A, B is often not live yet. You watch one record flow through, see it land where it should, and move on. The loop does not exist in that test, because a loop needs two active participants and a real automated write to set it off. A human nudging a single record never loops, because you stop after the first round trip. You see it work and you walk away.

The machine does not walk away. It keeps going. So the loop waits for the exact conditions your test never recreates: both sides live, an automated write, and nobody around to notice the second lap. That is why these things go off on weekends and over holidays. The quiet is not a coincidence. The quiet is the trigger.

Every write is also an event

Underneath all of this sits one assumption almost nobody says out loud: that a write from your own automation is somehow different from a click by a person. To the system, it usually is not. An "updated" event does not care who did the updating. An update is an update.

The moment two automations read and write the same data, you have built a circle, whether you meant to or not. A writes, B listens. B writes, A listens. The only real question is what breaks the circle. If your honest answer is "someone will probably notice," you do not have a safeguard. You have a delay in front of the same outcome.

Four ways we keep it from happening

We no longer build this kind of setup without at least one of these in place. On anything important, two.

The most reliable is to mark who wrote each change. When an automation writes, it should leave a fingerprint, a field that reads "last changed by: system" or a timestamp only it sets. The other side checks that fingerprint before it does anything and stops the moment the change came from its counterpart. This goes after the cause instead of the symptom, which is why I reach for it first.

Almost as useful is to write only when something actually changed. A surprising number of loops survive on pointless writes alone. An automation pushes "status: open" onto a record that already says "status: open," the system fires an update event anyway, and the wheel turns. Compare old against new before you write, and if they match, do nothing. That one habit starves a lot of loops.

The cleanest fix is one writer per field. Decide, for every field, which system owns the truth. Price comes from the shop, so only the shop writes price. Sales stage lives in the CRM, so the shop never touches it. Give each field a single owner and no circle can form, because two sides never fight over the same value. Genuine two-way sync, where both ends may write everything, is usually a design mistake dressed up as a feature.

And even with all of that, I want a hard stop for the thing I missed. A counter is often enough. If the same path runs more than, say, fifty times in five minutes, it shuts itself off and sends a message. I would rather chase a false alarm than find an empty account on Monday. This does not replace the other three. It is the net underneath them.

How this looks in the actual tools

In Make, the quickest route is an extra field plus a filter right after the trigger. When you write, you set a field like "changed by" to the name of the scenario, and at the start of its counterpart you add a filter that bails out the moment it sees the other side's name. Make still counts each aborted run as an operation, but one operation is a lot cheaper than forty thousand.

In n8n you have more room, because a Function or IF node lets you compare whatever you want. We read the old record there, compare field by field, and let the workflow end early when nothing relevant changed. If you self-host n8n, an idling loop does not eat an operations quota, it eats your CPU. The account does not freeze, but the server crawls, and the symptoms are harder to read.

Zapier is the most awkward of the three, because a Zap's logic is kept deliberately simple. Your best bet is a filter step plus the built-in protection that pauses a Zap when it triggers itself unusually often. Do not lean on that alone. It is a safety net, not a substitute for a clean design.

If it is looping right now

If you are reading this because something is spinning as we speak: stop first, understand later. Switch off either one of the two scenarios, it does not matter which. The circle breaks the second one side goes quiet, and that buys you time. Only then do you work out what got mangled in the meantime.

And something usually did. We once watched a timestamp field drift by a hair on every pass until, a few thousand rounds later, it held values no human had ever entered. Look at the affected records one by one before you arm the automations again. A backup from before the weekend is worth a great deal here, which is one reason we insist on data versioning for anything critical.

What it comes down to

Trigger loops are not an exotic beginner mistake. They grow out of one of the most ordinary requests there is, "keep these two systems in sync," and out of a belief that sounds wrong the instant you say it aloud: that your automations know when to stop. They do not. They do exactly what you told them, for as long as it takes something else to stop them.

So every time two automations touch the same data, the design has to answer one question from the start: what breaks the circle? If the only answer is a hope that someone glances at the right dashboard at the right moment, the question is not answered. It is postponed, usually to a weekend.