Starting on 1/26/26 none of our scheduled jobs run in any of our workflows. Most of the jobs we’ve seen the issue with use the “Schedule Trigger” node. Due to this, we upgraded our n8n cloud instance to v2. We unpublished, republished each workflow. We deleted and rebuilt the Schedule Trigger nodes. We even rebuilt multiple FULL workflows from scratch. Same result, trigger isn’t running. All of these jobs were running for months w/ no issue. Lastly, we even built a net new workflow to test a trigger from scratch (see below), set to run every five minutes. Other Schedule Trigger nodes are set to run daily, or every 2 hours. None of them run anymore. Some workflows are related to our business operations, and we rely on the consistency to do our work. Has anyone else seen this, n8n won’t give us attention even w/ a Sev1 ticket. Please help!!
The documentation doesn’t record an incident, but the behavior you’re observing is incompatible with any configuration error and clearly points to a scheduler failure on the n8n Cloud instance. While this isn’t resolved, the only reliable workaround is using an external cron like GitHub Actions, Cloudflare Workers, or a cron server to call a Webhook Trigger in n8n.
Oooof, that is not what I was hoping to hear. Thank you for the quick reply. So, in conclusion, we have an automation / workflow tool with no ability on its own to reliably run on a schedule…hrmmm, not good…
I completely understand your concern, and I want to clarify a few important points so we don’t jump to the wrong conclusion here.
First
just to realign expectations with the documentation:
On n8n Cloud, the Schedule Trigger is a managed service, and it’s not something that can silently “stop working” due to workflow configuration, publishing state, or node recreation. Rebuilding workflows or nodes wouldn’t affect the scheduler itself, so you were right to suspect this isn’t a normal config issue.
That said, this still doesn’t mean the scheduler is fundamentally unreliable or broken by design. What can happen, and this is documented behavior, is temporary scheduler disruption on a specific Cloud tenant, delayed or stuck trigger registrations after upgrades or internal maintenance, or a mismatch between workflow state and the scheduler registry that only Cloud support can reset. From a user perspective, all of these look identical because triggers simply don’t fire.
What's important to do next
is to ask Cloud support to verify and re-register scheduled triggers at the account level. Specifically mention the exact date and time when triggers stopped, which was January 26th, that new Schedule Trigger workflows also do not fire, and that this happens across all schedules and intervals. This gives them a concrete internal check to run. This is not something you can fix from the UI, and it’s not expected behavior.
About the webhook plus external cron workaround
it’s not a replacement for Schedule Trigger, and it’s not how n8n Cloud is intended to be used long-term. It is a temporary operational fallback that keeps business workflows running, avoids data loss, and buys time while Cloud support resolves the scheduler state. Many teams keep this pattern documented for incident response, even if they normally rely on native scheduling. hidden
So the correct conclusion here is not “n8n can’t reliably run scheduled workflows.” The accurate conclusion is “There appears to be a scheduler-level issue affecting this Cloud instance that requires intervention from n8n Cloud support.” That distinction matters, both technically and operationally.
Hello mburger23, I just tested a cron job in my cloud environment, and it worked.
Try to restart the workspace
Try to select another Time zone → save and select your time zone again → save
I appreciate the insight. I have a Sev1 ticket open for 3 days now but can’t get any attention other than automated responses. Let me kow if you think of anything else!
I appreciate the idea. I had already restarted the workspace multiple times. I did change the time zone, save, change it back, save…no luck I’m out of ideas and apparently a Sev1 ticket doesn’t get attention. Let me know if you think of anything else!
In my HomeLab I run n8n installed as a service on my Ubuntu Server without using Docker.
Whenever I have this issue with triggers not firing, I need to run systemctl restart n8n on the operating system.
From what I’ve researched, sometimes the scheduler doesn’t register correctly until the process is restarted. This happens because the scheduler runs inside the Node.js process and not as a separate service — so yes, it is actually a bug.
For people who use a VPS and only see the application in the cloud, it can be complicated in this case.
If you have access to Docker or to the operating system where your n8n app is installed, try restarting the service — it might solve the problem.
Hi @tamy.santos …n8n support eventually got back to us. They rebuilt our instance, and we also turned off all workflows and slowly turned them on one by one as we monitored the consistency of the scheduler. That was time consuming, but did the trick.
Hey @tamy.santos. Any workaround for local-hosted version? I got the exact same issue. Trigger node keeps spinning and following nodes are not fired up accordingly.
I’m out of ideas and apparently a Sev1 ticket doesn’t get attention. Let me know if you think of anything else!