I’m encountering recurring issues with double-firing workflows, and despite trying various solutions, I haven’t found a satisfactory resolution. I’ve attempted modifying the workflow, upgrading n8n, unpublishing and then republishing it, deleting it, and uploading it again. However, the problem persists, causing me to post twice and incurring twice the API cost.
This happens in almost every workflow that starts with a CRON node.
How can I fix this? I’m thinking to give up, delete every workflow, remove n8n and substitute everything with coded solution in my VPS, in the era of Agentic Coding is even more easy, less headaches and it always works.
Information on your n8n setup
- n8n version: Last updated version
- Running n8n via (Docker)
- n8n self hosted
@Sergio_Longhi double-firing that survives republish/delete/recreate almost always means u have TWO n8n processes both running the scheduler — either two containers from old/new compose runs both alive, or a worker enabled alongside main mode. quick check: docker ps | grep n8n on the VPS — is there more than 1 n8n container running? and what does ur EXECUTIONS_MODE and N8N_DISABLE_PRODUCTION_MAIN_PROCESS env look like in compose?
Welcome @Sergio_Longhi, I’m Jay, a Verified n8n Creator
From my experience, this kind of “double firing” often comes from a point in the workflow where it starts outputting 2 items, so everything after that naturally runs twice.
I’d suggest opening the Execution that showed the issue and checking each node’s Data tab to see where it goes from 1 item to 2 items.
Once you’ve found that spot, you can use an Aggregate node (or similar) to merge things back into a single item before continuing with the rest of the workflow.
Hope this points you to the real root cause and helps you fix it.
Hello Scham,
unfortunately it’s listed in the executions of the same workflow, sometime not even a second, some other time a few seconds, it’s really strange.
Both workflows begin with only one CRON node and everything start from that single node.
Thank you, d-hippolyte,
for acknowledging my frustration and the fact that it’s a bug (as I’ve heard from different LLMs). Most importantly, thank you for providing me with another solution.
I never attempted to delete the node, reload my Docker container, and reinstall it.
I’ll give this a try to see if it resolves the issue. I sincerely hope they’ll also fix this incredibly annoying problem.
Regards,
Sergio.
Could you share a screenshot of one of the actual workflow executions from the Executions log instead of the current editor view?
The screenshots you posted now don’t show the full item data flowing through each node, so it’s hard to see where things start to duplicate. If you can open a single execution that shows the issue and grab screenshots of a few key nodes (including their Data tab), it’ll be much easier to pinpoint what’s going on.
For example, a helpful screenshot would look something like this:
Happy to, @Sergio_Longhi Take your time doing these steps on your end. I hope this complete memory purge will permanently solve the problem. If you’d like, I can take a look at your docker-compose.yml file. Let us know how it goes.
Thank you, unfortunately all the executions got canceled last time I tried to delete and upload again the workflow.
For now, seems fine, no double posting.
Glad it calmed down, but I would not fully trust the delete-and-recreate fix yet. If the real cause was two schedulers, that purge clears the in-memory trigger registration for a while and it tends to come back after the next restart. Worth confirming the root cause now while it is quiet.
Quick way to tell which of the two diagnoses above actually applies: open the execution list and look at a pair of the duplicate runs.
If you see two separate executions with two different execution IDs at nearly the same timestamp, that is two scheduler processes firing the same CRON, which is what achamm is pointing at. One n8n instance plus a stray second container sharing the same database will both run the Schedule Trigger independently. Run `docker ps` and confirm you have exactly one process registering triggers. In queue mode the main instance should own scheduling, not the workers, so check EXECUTIONS_MODE and that a second main did not come up by accident.
If instead you see a single execution ID but the downstream nodes ran twice, that is the data-duplication case nguyenthieutoan described, and the fix lives upstream: a node emitting 2 items, or a Merge or loop fanning out. An Aggregate or a Limit node before the expensive API call contains the cost there.
The two look identical from outside but the fixes are unrelated, so the execution ID is the fastest thing to check. Once you know which one it is you can close it properly instead of waiting to see if it returns.
Sounds like you’ve got more than one n8n process running and they’re both firing the cron. That’s almost always what’s going on when every schedule-triggered workflow doubles up on self-hosted — the workflow itself is fine; it’s just getting triggered twice.
What I’d check, in order:
- docker ps — confirm there’s only one n8n container. A leftover/duplicate from an old docker compose up is the usual suspect; I’ve walked into setups with a second container nobody remembered was still running.
- If you’re on queue mode (EXECUTIONS_MODE=queue), check how many main processes you have. Workers are fine, but two mains will each schedule the cron unless multi-main leader selection is set up. Two mains = two fires.
- If the stack ever got started twice (compose in two folders, or an old container next to a new one), kill the extra.
Quick way to confirm it’s a duplicate trigger and not a workflow bug: drop a Set node right after the cron that logs $now + the execution id. If you see two executions a second or two apart every run, it’s a second instance firing.
One more thing regardless of the cause — for anything that costs money per run, I’d add an idempotency guard (hash a key for the run, skip if you’ve already seen it in the last X seconds). That way even a stray double-fire can’t bill you twice. Cheap insurance.
Honestly though, before you tear it all out for code on the VPS — this is a duplicate-instance config thing, not an n8n flaw. Worth 10 minutes with docker ps first.
Still double firing an also another workflow that insert leads into a google sheet (CRM) is double firing. This thing is very upsetting.
Don’t give up on n8n just yet, this is actually a well known issue with self-hosted Docker setups and it’s very fixable.
The double-firing almost always comes down to running multiple n8n instances at the same time. What happens is Docker restarts a container without fully stopping the previous one, so two instances end up running together and both pick up the same CRON trigger at the same time.
First thing I’d check is whether you have more than one n8n container running:
docker ps | grep n8n
If you see more than one entry, that’s your problem. Stop all of them and start fresh with a single container.
Second thing to look at is your execution mode. Add this to your Docker run command or docker-compose file if it’s not already there:
N8N_EXECUTIONS_PROCESS=main
Also double check that you’re not accidentally running n8n as both a main instance and a worker on the same machine ,that alone can cause this.
If you’re on docker-compose, review your restart policy as well. An aggressive restart policy can spin up duplicate containers on crash or reboot without you realizing it.
The fact that this happens across almost every CRON workflow tells me it’s a container/instance issue rather than anything wrong with your individual workflows. Sort out the duplicate container situation first and I’m pretty confident this goes away completely.
Thank you very much, Samuel. This was precisely the issue, and it’s now resolved
I also appreciate you pointing out the N8N_EXECUTIONS_PROCESS=main. It was an old installation, and it was missing.
I owe you one.
