# n8n Workflow Not Triggering? How to Find the Cause

*How-to — 2026-11-11 — by Mahmoud Zalt*

Why an n8n workflow runs manually but never on schedule: publishing, timezone, cron syntax, execution logging and concurrency limits, checked in order.

**Short answer.** **If the workflow runs when you press the button but never runs on its own, start with publishing, then timezone, then whether executions are being saved at all.** Those three account for most cases. A trigger that never fires produces no failed execution and no error, so the absence of evidence is the symptom, not a dead end.

**About this guide.** This guide is based on n8n's own documentation and public community reports, checked on 17 August 2026. Sistava is not affiliated with n8n. Setting names and interface labels change between versions, so confirm the current steps in n8n's documentation before you rely on them. Where a cause comes from a community thread rather than the docs, it says so.

This is the most frustrating category of n8n problem, because nothing is broken in a way you can point at. The workflow is there. You press Execute and it works end to end. You come back the next morning and the executions list is empty.

The reason it feels impossible is that a run which never starts cannot fail. There is no red node, no error message and no entry in the log, because n8n never began an execution to record. You are debugging an absence.

So work backwards from the trigger rather than forwards from the nodes. The order below goes from the causes that account for most cases to the ones that are rare but real, and each step has a check you can actually perform rather than a thing to eyeball.

## Is the workflow published, or only saved?

A trigger only fires for the published version of a workflow. Since n8n 2.0 this is a separate action from saving: n8n's own help material states that saving stores your changes without affecting production, and Publish is what makes them live. If you learned n8n on the older active and inactive toggle, this is the single most likely cause.

The trap is subtle, because a workflow can be published and still be running old logic. You open it, make a change, hit Save, and production keeps serving the version you published last week. Nothing in the executions list tells you that, since the runs you see are perfectly real, they are just running the previous version.

The same rule reaches sub-workflows. n8n's 2.0 breaking changes note that parent workflows can only reference published versions of sub-workflows, so an unpublished child will not pick up your edit no matter how many times you save it.

## Did you change the schedule without republishing?

Changing the interval on a Schedule Trigger does nothing until you publish again. n8n documents this directly, and adds a second behaviour that catches people out: the schedule begins from the time you publish the workflow, so execution times are recalculated from the new publish timestamp rather than continuing on the old rhythm.

Variables behave the same way. n8n's documentation says variable values used in the Schedule Trigger are only evaluated when the workflow is published, so changing a variable afterwards has no effect until you republish. If your schedule reads a variable and refuses to update, that is why.

1. **Open the workflow and check its published state** — Not saved. Published. If you have edited anything since the last publish, publish again so the live version matches what you are reading.
2. **Note the exact time you published** — The schedule counts from that moment. An hourly trigger published at 10:47 fires at 11:47, not on the hour.
3. **Check the timezone the workflow is using** — Compare the workflow setting, the instance timezone and your own. A schedule set to 09:00 in a UTC instance fires at a different local time for you.
4. **Confirm executions are being saved** — If production execution data is not saved, successful runs leave no trace and you will read that as nothing happening.
5. **Watch one interval live** — Pick a short interval, publish, and wait for it. If it fires now but not at your real interval, the problem is the schedule expression or the timezone, not the trigger itself.
6. **Attach an error workflow before you leave it** — So the next failure reaches you instead of sitting silently in a list nobody opens.

## Is n8n running in a different timezone than you?

If a scheduled workflow runs at the wrong time rather than not at all, the timezone is almost always the cause. n8n lists this as a documented common issue for the Schedule Trigger and gives three places to set it: globally in n8n Cloud settings, with the GENERIC_TIMEZONE environment variable on self-hosted instances, or per workflow through the Settings menu.

Servers default to UTC far more often than people expect, and a community thread on a workflow that would not run on schedule landed on exactly this: the server was running in a different time to the browser where the schedule was set. It is worth checking even when the gap looks too small to matter, because a job set for 23:30 in one zone can land on the wrong calendar day in another.

If publishing and timezone both check out, the remaining causes split into two groups. Either the schedule expression itself is wrong, or the workflow is running and you cannot see it. The second group is more common than people assume, and it wastes hours because you spend them looking at the wrong half of the problem.

## Is the cron expression valid?

n8n lists an invalid cron expression as a documented common issue for the Schedule Trigger, and the fix is to check your expression against the syntax in their docs and validate it with a tool such as crontab guru. Custom cron is where most schedule bugs live, because a syntax that is very slightly wrong still looks reasonable.

Where you can, use the interval options rather than writing cron by hand. Every minute, every hour and every day at a set time cover the vast majority of real needs, and they take the expression out of the equation entirely.

## Are your executions actually being saved?

This is the cause people miss. n8n controls what goes into the executions list with environment variables, and if saving is turned off for the relevant outcome then successful runs leave no trace. You read an empty list as a trigger that never fired, when in fact the workflow ran fine every hour.

The variables to look at are EXECUTIONS_DATA_SAVE_ON_SUCCESS and EXECUTIONS_DATA_SAVE_ON_ERROR, which each accept all or none, plus EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS for the runs you start by hand. If you inherited a docker-compose file from a tutorial, check what it set.

Pruning is the other half of this. n8n prunes finished executions on a schedule by default, using a maximum age of 336 hours, which is 14 days, and a maximum count of 10,000 executions before it starts deleting oldest first. Old history disappearing is expected behaviour, not data loss, and annotated executions are never pruned if you need to keep one.

This is the cost of owning the runtime. Nobody tells you a schedule stopped, nobody notices that history was pruned before you needed it, and the checking is yours forever. Work that watches itself is a different arrangement: at [Sistava](/hire-ai-employees) you hire an AI Employee, tell it what you want done and when, and the reporting back is part of the job rather than something you bolt on afterwards.

Two rarer causes are left, and both are worth knowing because neither looks like a trigger problem from the outside. One is a limit you set on purpose, and the other arrived with a major version upgrade.

## Is a concurrency limit holding runs in a queue?

If you set N8N_CONCURRENCY_PRODUCTION_LIMIT, executions past the limit wait in a queue until capacity frees up and are then processed in the order they arrived. The run is not lost, it is late, which reads as a missed trigger if you are only checking whether something ran at nine o'clock.

n8n documents that this limit applies to production executions started by webhooks or trigger nodes, and not to manual executions or sub-workflows. That difference explains the classic symptom exactly: your manual run goes straight through while the scheduled one sits behind everything else.

## Did an upgrade change your trigger?

n8n 2.0 removed the legacy Start node. Their breaking changes page says to replace it with the Manual Trigger for manual runs or the Execute Workflow Trigger for sub-workflows, or to delete it if it was disabled. An old workflow that relied on it will not simply carry on.

The command line changed in the same release. The update:workflow command was replaced by publish:workflow and unpublish:workflow, and the all parameter was removed to prevent accidental production deployments. If you had a script that activated workflows in bulk, it stopped working at that upgrade rather than gradually.

## How do you get told the next time it stops?

Set up an error workflow. Create a workflow whose first node is the Error Trigger, then in the workflow you care about open Options and then Settings and pick it in the Error workflow dropdown. n8n notes that one error workflow can serve many workflows, so this is a single piece of setup, not a per-flow chore.

The Error Trigger receives useful context by default, including the execution id and url, the error message, and lastNodeExecuted so you know which node gave up. n8n also flags that when the trigger node itself is what failed, the data arrives in a different shape, nested under trigger.error rather than execution.error, so handle both if you parse it.

## What this will not catch

An error workflow only fires when an execution fails. It cannot tell you that a scheduled run never started, because there was no execution to raise an error from. If silent non-firing is your risk, you need an outside check, such as a monitor that expects a signal from the workflow at a set time and complains when it does not arrive.

There are also open community reports of schedule triggers that stop firing on published workflows with no error at all, sometimes fixed by deleting and recreating the trigger node. That is a workaround people report rather than documented behaviour, and if it happens to you repeatedly it belongs in a support ticket with your version number, not in another round of checks on your own configuration.

The honest summary is that a schedule is a promise your infrastructure makes and does not verify. You own the clock, the process and the noticing. If you would rather own the outcome instead, that is the whole idea behind an AI Employee at [Sistava](/signup), which reports on the work it did rather than leaving you to infer it from a list.

Whatever you run on, do one last thing before you close the tab. Write down the interval you expect and the time you last saw a real execution, somewhere you will actually look. Most silent stops are discovered weeks late, and the cost is never the fix, it is the weeks.

## FAQ

### Why does my n8n workflow work manually but not on schedule?

Check publishing first. Since n8n 2.0, saving a workflow stores your changes without affecting production and Publish is the action that makes them live, so an edited workflow can be saved and still be serving an older published version. If it is definitely published, check the timezone next, since n8n lists a timezone mismatch as a documented cause of scheduled workflows running at the wrong time. After that, confirm that execution data is actually being saved, because runs that are not recorded look identical to runs that never happened.

### Do I need to republish an n8n workflow after changing the schedule?

Yes. n8n documents that changes to the trigger interval only take effect after you publish the workflow again, and that the schedule begins from the time you publish. That means execution times are recalculated from the new publish timestamp rather than continuing on the old pattern. Variables used in the Schedule Trigger behave the same way and are only evaluated at publish time.

### How do I set the timezone for n8n schedules?

n8n documents three levels. On n8n Cloud you set it in your instance settings. On self-hosted instances you set the GENERIC_TIMEZONE environment variable. For a single workflow you can override it through the workflow Settings menu. Servers commonly default to UTC, so if a schedule fires at the right interval but the wrong hour, this is the first place to look.

### Why is my n8n executions list empty even though the workflow runs?

Because execution data may not be saved. n8n controls this with the EXECUTIONS_DATA_SAVE_ON_SUCCESS and EXECUTIONS_DATA_SAVE_ON_ERROR variables, which accept all or none, plus EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS for manual runs. Pruning also removes old records: by default n8n prunes finished executions older than 336 hours, which is 14 days, and starts deleting oldest first once there are more than 10,000.

### Can an error workflow tell me when a trigger stops firing?

No. An error workflow runs when an execution fails, and a trigger that never fires produces no execution to fail. Error workflows are still worth setting up, using the Error Trigger node and the Error workflow dropdown under Options and Settings, because they catch everything that runs and breaks. To catch a silent stop you need an external check that expects a signal at a set time and raises an alarm when nothing arrives.

### Why do my scheduled runs happen late in n8n?

Check whether you have set N8N_CONCURRENCY_PRODUCTION_LIMIT. When the limit is reached, n8n documents that executions remain in the queue until capacity frees up and are then processed in the order they arrived. The limit applies to production executions from webhooks and trigger nodes but not to manual executions or sub-workflows, which is why a manual run can appear instant while the scheduled one is delayed.

## Sources

- [n8n documentation, ](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.scheduletrigger/common-issues)Schedule Trigger common issues
- [n8n help centre, ](https://support.n8n.io/article/understanding-workflow-publishing-in-n-8-n-2-0)Understanding workflow publishing in n8n 2.0
- [n8n documentation, ](https://docs.n8n.io/changelog/v20-breaking-changes)v2.0 breaking changes
- [n8n documentation, ](https://docs.n8n.io/deploy/host-n8n/configure-n8n/scaling/manage-execution-data)Manage execution data
- [n8n documentation, ](https://docs.n8n.io/deploy/host-n8n/configure-n8n/scaling/control-concurrency)Control concurrency
- [n8n documentation, ](https://docs.n8n.io/build/flow-logic/handle-errors-gracefully)Handle errors gracefully
- [n8n community forum, ](https://community.n8n.io/t/active-workflow-not-executing/219822)Active workflow not executing

**Tags:** n8n, troubleshooting, schedule-trigger, automation, workflow-automation