My workflow execute 1 time but send 2 messages please help

[FernandoS]

I have this workflow in n8n that I use to send messages on WhatsApp. I have two groups, and over the last week, it started sending duplicate messages to both groups. However, when I run a manual test (forcing execution or changing the schedule trigger time), it sends only one message correctly. But the next day, it starts sending two messages again

I have this workflow in n8n that I use to send messages on WhatsApp. I have two groups, and over the last week, it started sending duplicate messages to both groups. However, when I run a manual test (forcing execution or changing the schedule trigger time), it sends only one message correctly. But the next day, it starts sending two messages again

What is the error message (if any)?

Please share your workflow

Share the output returned by the last node

Information on your n8n setup

• n8n version:
• Database (default: SQLite):
• n8n EXECUTIONS_PROCESS setting (default: own, main):
• Running n8n via (Docker, npm, n8n cloud, desktop app):
• Operating system:

[musharraf39]

This is a common issue with scheduled workflows. Here are the most likely causes:

1. Duplicate Schedule Triggers

Check if you have:

Two Schedule Trigger nodes active

Same workflow activated twice

Multiple cron jobs pointing to the same workflow

Quick fix: Deactivate the workflow, refresh the page, then reactivate.

2. Execution History Replay

Sometimes n8n replays missed executions. Check:

Execution history for duplicate runs

If you see 2 executions at the same time, that’s the issue

Solution: Set N8N_SKIP_WEBHOOK_DEREGISTRATION_SHUTDOWN=true in your environment.

3. Loop in Your Workflow

Looking at your screenshot, check if:

The Switch node is creating a loop back

Both paths execute the same WhatsApp node

To debug:

Check execution history - do you see 1 or 2 executions?

Add a “Set” node before WhatsApp with: {{ $now.toISO() }} to timestamp each run

Check if both groups are in a single array causing iteration

Can you share:

How many executions show in history when it sends duplicates?

Your workflow JSON (the code)

[FernandoS]

Sure i can do this. In my json has any private data?

[Ken_Chan1]

Hi! This is a classic issue that usually points to an infrastructure or configuration overlap rather than a bug in your nodes—especially since manual tests work perfectly.

Since you are seeing duplicates only during scheduled runs, here are the most likely culprits and how to fix them:

1. The “Ghost” Instance (Most Common)

If you are running n8n in Docker or on a VPS, you might have an old container or process running in the background that you forgot to stop.

• The Test: Turn off your current n8n instance/container entirely. Wait for the scheduled time. If messages are still sent, you have a “zombie” instance running elsewhere with the same database.

• The Fix: Ensure only one Docker container is active and check for duplicate cron jobs on your server.

2. Workflow Overlap

Check your Workflows list and search for any old versions or backups of this same project.

• The Fix: Make sure you don’t have a “Copy of…” workflow also set to Active. Even if you changed the name, the Schedule Trigger will still fire.

3. Execution Retries

Check the Workflow Settings (the gear icon in the left sidebar).

• The Fix: Ensure “On Fail - Retry” is disabled. If the WhatsApp node hits a minor network timeout, n8n might be retrying the entire workflow from the beginning, causing a second set of messages to go out.

4. Check the Execution History

Go to your Executions tab in n8n and look at the time the duplicates happened:

• Two separate Execution IDs: This means the workflow was triggered twice (see points 1 and 2).

• One Execution ID: This means there is a loop or a logic issue inside the workflow (like a “Split In Batches” node sending data back to the start) that is being processed differently under schedule.

5. Database Connection (SQLite vs Postgres)

If you are using the default SQLite database and your server is under high load during the scheduled time, the “lock” on the database might fail, causing the scheduler to trigger the event twice.

• Quick fix: Try adding a Wait Node (set to 5 seconds) immediately after your Schedule Trigger to give the database time to register the start of the execution.

Hope this helps! Let us know what you find in the Execution history, as that will narrow down the cause significantly.

[FernandoS]

Hey, thank you! You were right about the ‘Ghost’ instance. I found duplicate containers executing simultaneously in my Docker environment