Vivere

Vivere / Answers

n8n Schedule Trigger not firing: what to check

A Schedule Trigger that stops is almost always one of six things, and most of them are invisible from inside n8n.

An n8n Schedule Trigger that has stopped firing is frustrating precisely because the editor looks fine: the workflow is there, the node is there, and pressing Execute Workflow runs it perfectly. Here is what to check, roughly in order of how often each one is the answer.

1. The workflow is not active

This is the most common cause by a wide margin. A Schedule Trigger only fires for a workflow whose Active toggle is on. Running it from the editor executes the workflow once for testing and schedules nothing.

It is easy to end up inactive without meaning to: saving a new version of a workflow that was never activated, importing a workflow from JSON (imports arrive inactive), or restoring one from a backup.

2. The instance restarted, and missed runs are not caught up

Schedule Triggers are timers inside the running n8n process. If the instance was stopped, restarting, redeploying, or being updated when a schedule was due, that execution does not happen and nothing records that it was skipped. There is no catch-up and no missed-execution entry to find later.

This matters most for infrequent schedules. A workflow that runs once a day at 03:00 and an instance that redeploys at 03:00 can miss days in a row while looking healthy in the executions list, because the list only shows executions that happened.

3. The timezone is not the one you are thinking in

n8n uses the instance timezone from GENERIC_TIMEZONE, which defaults to UTC, unless a workflow overrides it in Workflow settings → Timezone. A schedule set for 09:00 on an instance left at UTC runs at 09:00 UTC, whatever your local clock says.

Set both deliberately. If you run workflows for several regions, set the timezone per workflow rather than relying on the instance default, so that moving the instance does not silently move every schedule.

4. The workflow was deactivated by failures

n8n can deactivate a workflow whose trigger repeatedly errors, and depending on version and settings it does so without much fanfare. Check the executions list for a run of failures ending at the point the schedule stopped, and check the workflow's active state again after a failure cluster.

5. Queue mode, workers and which process owns the trigger

In queue mode, the main instance owns triggers and schedules; workers execute. If your main instance is the one that keeps restarting, or if you scaled the main process to zero, nothing is scheduling even though workers are healthy. Conversely, if there are no available workers, executions queue rather than run, which looks like a schedule that fired late rather than one that did not fire.

6. The interval is not what it reads like

A Schedule Trigger set to Custom (Cron) accepts a cron expression, and n8n's parser supports a seconds field. A five-field expression and a six-field expression with the same digits mean different things, and 0 */5 * * * * is every five minutes while */5 * * * * in the six-field parser is every five seconds. When in doubt, use the interval mode rather than an expression.

Knowing when a workflow goes quiet

An Error Workflow does not close this gap, because it reports executions that fail and most of the causes above produce no execution to report. The pattern that catches all six causes at once is to have the workflow prove it ran, from outside n8n. Add an HTTP Request node as the last node on the success path, pointed at a heartbeat URL:

Method: GET
URL:    https://vivere.dev/p/<your-monitor-id>

Then tell the monitor how often to expect it. If the workflow is deactivated, if the instance is down at the scheduled minute, if the timezone moved the run, or if the workflow errors before reaching that node, the ping does not arrive and you are alerted. Add a second HTTP Request node on the error output pointed at /fail and you are alerted immediately on an error instead of waiting for the deadline.

This works the same way for Make, Zapier and any other automation platform that can make an HTTP request as a final step.

Common questions

Why is my n8n Schedule Trigger not running?

The most common cause is that the workflow is not active. A Schedule Trigger only fires for an activated workflow; pressing Execute Workflow in the editor tests it but does not schedule it. After that, check the instance timezone, whether the instance was restarted or redeployed, and whether the workflow was deactivated by repeated failures.

Does n8n run schedules it missed while it was down?

No. A Schedule Trigger fires on a timer inside the running process. If the instance was stopped, restarting, or redeploying when a schedule was due, that execution simply does not happen and nothing records that it was skipped.

What timezone does an n8n schedule use?

The instance timezone from GENERIC_TIMEZONE, unless the workflow overrides it in its own settings. An instance left at the default UTC while you think in local time is a common cause of a job that appears to run at the wrong hour or to skip a day around a clock change.

Find out without looking

Vivere watches for the ping that does not arrive. Add one line to the job, pick where alerts should land, and you hear about the run that never happened.

Start free Read the quickstart

Ten monitors, a status page, email and webhook alerts. No card.

Last reviewed September 2026.

Related