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 the run was dropped

By default, 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.

Newer versions can fix the restart case, if you turn it on. From n8n 2.36.0, and as a preview since 2.32.0, the durable scheduler records upcoming runs in the database, so a restart no longer loses them. It is off by default. It needs both N8N_SCHEDULER_ENABLED and N8N_USE_WORKFLOW_PUBLICATION_SERVICE set to true; with only the first, Schedule Triggers stay on the in-memory scheduler and n8n logs a warning.

It has limits worth knowing before relying on it. A run that is later than its grace period, one minute unless you change it, follows the trigger's misfire policy, and the default, Don't Run Missed Executions, discards it exactly as before. A restart that takes three minutes therefore still loses the run on default settings. Choosing Run the Most Recent Missed Execution gives you a catch-up, but a backlog of missed runs collapses into one, so a workflow that works out its date range from the current clock still covers the wrong span. And it only helps once the instance is back: a host that stays down or a database it cannot reach still means nothing fires.

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.

The number worth thinking about is how late the ping may be before it counts as missing. A busy instance starts a workflow some minutes after its scheduled time, so that allowance is the workflow's worst normal run plus the delay plus a margin, taken from the durations you already have in the executions list rather than picked round. A calculator for it is free and runs in your browser.

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?

Not by default. A Schedule Trigger normally fires on a timer inside the running process, so a run that was due while the instance was stopped, restarting, or redeploying simply does not happen and nothing records that it was skipped. From n8n 2.36.0 the durable scheduler, which is off until you enable it, keeps upcoming runs in the database. Even then, a run that is later than its grace period (one minute by default) is discarded unless the trigger's misfire policy is set to run the most recent missed execution.

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

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

Last reviewed September 2026.

How to get an alert when an n8n workflow doesn't run — n8n tells you when a workflow fails, not when it does not run: an unpublished workflow, a schedule lost to a restart, a webhook nobody calls, an instance that is down. What n8n offers on its own, where each part stops, and the dead man's switch that covers the rest.
Cron job not running: how to find out why — A cron job stopped running and nothing told you. The five usual causes in the order worth checking, how to read the logs, and how to find out next time without looking.
A dead man's switch for your scripts — What a dead man's switch is, why it catches failures that error-based alerting cannot, how to build one with cron and curl, and the timing rules that stop it crying wolf.