Your Automation Tool Will Send That Message Twice

The send worked and the response did not#

Picture a timeout on a send request. The message left, the recipient's phone lit up, and the connection dropped before the confirmation came back. Your workflow tool sees an error.

No automation tool can tell that apart from a request that never arrived. Both look like a step that failed, and the safe-looking response to a failed step is to run it again.

On a database write, running it again is correct. On a message send, running it again puts a second copy of your sentence in front of a person who already read the first one.

• The failure mode has a name in distributed systems: at-least-once delivery. A retry guarantees the request lands eventually, and makes no promise that it lands only once.
• Message sends are the case where at-least-once is expensive, because the duplicate is not a wasted row in a table. A human reads it and draws a conclusion about you.
• The gap is usually short. A send that times out at ten seconds and gets retried at eleven puts two identical texts in the thread inside one breath.
• Nothing here is a bug in the workflow tool. Retrying is the correct default for almost everything else these tools connect.

What each tool actually does on an error#

Three tools drive most of the outbound messaging built without a developer, and all three publish their retry behavior. Read your own before you assume it does nothing.

n8n puts the control on the node. A node setting called Retry On Fail reruns the node until it succeeds, and a second setting called On Error decides whether the rest of the workflow keeps going.

Zapier and Make put the control higher up, on the whole run rather than one step, which means a retry can repeat work that already completed.

• n8n: "Retry On Fail: When an execution fails, the node reruns until it succeeds." On Error offers Stop Workflow, Continue, and Continue using error output (docs.n8n.io/workflows/components/nodes, read 17 September 2026).
• Zapier: autoreplay "will automatically replay any Zap run with an errored status", and it is available on Free through Enterprise, set account-wide or per Zap (help.zapier.com replay article, updated 29 May 2026, read 17 September 2026).
• Make: a connection error or module timeout triggers exponential backoff, which reruns the scenario up to eight times. First rerun at one minute, then ten minutes with incomplete executions enabled (help.make.com/exponential-backoff, read 17 September 2026).
• Eight scenario reruns is the number to sit with. A send step inside that scenario can fire eight times off one trigger if nothing upstream blocks it.

A duplicate costs more on a threaded channel#

Email hides a duplicate reasonably well. Two copies arrive as two rows in a list, the reader deletes one, and the cost is a moment of mild confusion.

A blue-bubble thread has no list. The second copy sits directly under the first, in the same conversation, timestamped a minute later, with no subject line to explain it.

What the reader concludes is specific and hard to walk back. A person texting them would not paste the same sentence twice, so the sender is software, and the message is a broadcast.

• The whole reason the channel works is that it reads as one person writing to one person. A visible duplicate removes that in a single glance.
• Recovery is worse than the duplicate. An apology text is a third message in a thread that has already turned, and it spends your one good opening on housekeeping.
• Reports are the real risk. Apple treats a spam report as a switch rather than a score, and a thread that looks automated is the kind that gets reported.
• First messages are where this hurts most. Read why the first message should carry no link for the rest of that opening-move problem.

The daily cap is the second currency#

Sending capacity on this channel is counted per line per day, and published by the vendors worth buying. A duplicate spends that capacity on a contact you already reached.

Arithmetic makes the point faster than argument. A retry storm that doubles a morning's sends does not double your reach, it halves the number of new people you got to.

Worth checking on your own account: whether the vendor counts a retry as a new conversation or as a message in an existing one, because those hit different published limits.

• Tuco AI publishes roughly 50 new contacts and roughly 150 total outbound messages per line per day (tuco.ai/ai-instructions, read 17 September 2026). Duplicates come out of the 150.
• Blue Reacher publishes no total daily message cap and never meters replies. New conversations pace at 50 opted-in and 30 cold per line per day.
• Run the multiplication before you trust a sequence: sends per contact, times contacts per day, times the number of retries your tool will attempt on a bad afternoon.
• Per-message billing turns the same bug into an invoice. See how a message credit gets counted if your vendor bills by volume.

Suppression living in the wrong system#

Opt-out handling breaks in a way that has nothing to do with retries, and it breaks in the same builds. Ask one question: which system decides that the next message does not go?

Reply text lands on the messaging platform. Queued steps usually live in the automation tool or the CRM. When the two are not wired together, a stop word arrives and the next step still fires.

Timing decides whether anyone notices. A sequence with a two-day gap gives you two days to sync. A same-day follow-up gives you minutes.

• The rule in force requires honoring a revocation within a reasonable time not to exceed ten business days. The FCC has asked whether that should drop to seven (draft FCC-CIRC 2609-05, circulated 9 September 2026, read 17 September 2026).
• Neither number is the one that matters operationally. The number that matters is the gap between the reply arriving and the next queued send being cancelled.
• Check suppression at send time, not at the moment the step was queued. A list built at 9am and sent at 2pm carries five hours of stale consent.
• Our handling of stop words sits on the platform that holds the thread: see opt-out handling and the draft FCC opt-out order.

Order is not guaranteed either#

Workflow tools process items in batches and often in parallel, which is what makes them fast. Fast and ordered are different properties, and only one of them is promised.

Two messages queued a second apart can arrive in either order. In a sequence where message two references message one, the reversal reads as a mistake to the person holding the phone.

Retries make the reversal more likely, because a retried step lands after everything that was queued behind it while it was failing.

• Test it rather than assume it. Queue a three-step sequence against your own number and read the thread in the order it actually arrives.
• Sequencing belongs on whichever system owns the conversation, because that system is the only one that knows what was already delivered.
• A workflow tool is a good trigger and a poor scheduler. Let it say what happened and let the messaging platform decide what goes next.
• Ordering bugs hide in testing. One contact, one thread, no concurrency, and it works every time until the list is 400 long.

The fix is a key and an owner#

Two changes remove most of this, and neither needs a rebuild. Give every send an identifier, and name one system as the owner of the decision to send.

An idempotency key is an identifier that describes the message rather than the attempt. Same contact, same step, same day produces the same key, and the platform ignores the second arrival.

Key design is the part people get wrong. A key built from a timestamp or a run id changes on every retry, which makes it a label rather than a guard.

• Build the key from stable inputs: contact id, sequence id, step number. Never from the current time, a random value, or the execution id your tool generates.
• Name one owner. If the automation tool decides what goes out, the messaging platform must not also schedule. Two schedulers on one thread is the same bug wearing a different hat.
• Log the key on both sides. A duplicate you cannot trace is a duplicate you will argue about instead of fix.
• Blue Reacher speaks to n8n, Make and Zapier through webhooks and the REST API, with the send decision and the suppression check on our side of the line.

An hour with a live automation#

Nothing below needs a developer, and all of it can run against your own phone number this afternoon. Work through it on one real sequence rather than on a diagram.

Start with the settings you have never opened. Retry behavior is usually on by default somewhere in the stack, and most teams find out during a campaign.

Finish with a written answer to one question: when a send times out, what stops the second copy? A build with no answer to that has a duplicate in its future.

• Open every send step and write down its retry setting, its error setting, and how many attempts it will make.
• Force a failure. Point the send step at a bad endpoint for one contact, then count the attempts in the run log.
• Send yourself a stop word mid-sequence and time how long the next queued message takes to disappear.
• Queue three steps at once against your own number and check the arrival order in the thread.
• Write the idempotency key you would use for message two of sequence four to contact 91, and check it stays the same if you run it again.

Frequently asked questions