The n8n workflow ran twice, and no one noticed.

The n8n forum analyzed one of the most unpleasant classes of automation errors: a workflow runs twice and performs the same side effect both times.

The customer receives two welcome emails, the account is charged twice, and the lead enters the CRM three times.

The main point of the analysis: without idempotency, automation outcomes depend on luck, and you discover a duplicate only after the execution logs have been deleted.

Initial analysis: Your n8n workflow runs twice and nobody notices: idempotency patterns that fix it, n8n community.

A failed workflow is immediately visible: a red status, an alert, and an investigation. A duplicate looks like a success.

Both runs finished successfully, and the “requests processed” metric increased.

The analysis author notes that the problem is discovered weeks later through a customer complaint or an accounting discrepancy. By then, the execution history is gone, so there is no way to determine which run was unnecessary.

For a business owner, it means money and reputation.

A duplicate charge turns into a refund, apologies, and an investigation with the payment provider.

A triplicate lead in the CRM disrupts the funnel: managers waste time on duplicates, while the conversion report shows incorrect figures.

There are three sources, all standard ones. Retry On Fail.

The node calls an external API, receives a timeout, and retries the request.

A timeout only means that no response arrived; the request itself may already have been completed on the recipient's side.

The retry sends it again. Webhook redelivery.

Payment and e-commerce providers, including Stripe, redeliver an event if they do not receive a fast 2xx response.

While the workflow processes the event, the provider has time to send it a second time. Manual restart.

The operator sees an error in the middle of the chain and starts everything from the beginning.

Steps that have already completed run again. The common root of all three is delivery guaranteed at least once.

The developer must build the exactly-once guarantee on their side.

for example, the provider's event ID, or build it from business fields: order number plus action type.

The execution time is not suitable as a key; every retry has its own. - Processed-key store.

A database table with a unique index on the key.

Inserting a new key succeeds; inserting an existing one fails, and the workflow ends without taking action.

Checking whether a record exists and inserting it as a separate step leaves a race window, so a unique index is more reliable. - Idempotent operations instead of inserts. Upsert by external ID in the CRM instead of create: a repeated call brings the record to the same state. - An idempotency key in the API call.

If the external service accepts this header, pass it along, and a retry will return the result of the first call. - A quick webhook response.

Accept the event, put it in the queue, and respond with 200.

The heavy processing runs after the response, so the provider has no reason to redeliver the event.

None of this looks impressive, so demonstrations do not show it.

In n8n releases 2.42.6 and 2.43.3, the platform began blocking the creation and updating of workflows with deprecated nodes.

The n8n developers addressed one class of silent problems at the platform level.

The platform will not prevent reruns for you: this part must be designed by whoever builds the process. In a related thread about an MCP endpoint with verified business facts, a participant describes another form of silent error: checking data freshness before loading it into RAG.

He also notes the limitation: an acceptable observation age does not prove that the fact is still true, and a recently collected page may already be incorrect.

The conclusion is the same: the boundaries of automation guarantees must be documented in advance.

The forum is full of posts like “I build AI automations and save time.”

: n8n, agents, RAG, email response generator, lead enrichment.

This stack can be assembled in an evening, and the first run looks convincing, meaning the time to the first result is short.

The time to a result you can trust with money is determined by other questions: what happens on the hundredth duplicate, during a provider timeout on Friday evening, or after a manual restart. In KT.Team integration projects—whether connecting 1C to an online storefront, exchanging data with a PIM such as Pimcore or Akeneo, or using Apache Kafka queues—idempotency is built into the exchange contract before the first line of code.

For Kafka events, it is the message key and a table of processed offsets.

For AI agents in n8n, it is a task key that makes a repeated run return the previous result.

The business sees a simple outcome: the email was sent once, and the invoice was issued once.

It relies on substantial engineering work that remains invisible as long as it is done well.

Initial analysis: “Your n8n workflow runs twice and nobody notices: idempotency patterns that fix it”

, n8n community, https://community.n8n.io/t/your-n8n-workflow-runs-twice-and-nobody-notices-idempotency-patterns-that-fix-it/320198.

Platform changes: n8n releases 2.42.6 and 2.43.3 on GitHub (n8n-io/n8n).

Forum materials license: n8n community terms.

The conclusions and examples concerning Kafka and integrations belong to the KT.Team editorial team.