Skip to content

n8n Workflow Not Triggering on Schedule? How to Fix the Schedule Trigger

Your n8n workflow has a Schedule Trigger, it's published, and running it by hand works. But the scheduled runs aren't happening, or they happen at the wrong time, or they "succeed" without doing anything. Nobody gets a warning: n8n's error workflows run when an execution fails or a trigger can't be activated, and a scheduled run that never started does neither.

The checks below start with the most common causes, and each comes with the command or screen to look at. We ran them on self-hosted n8n 2.43.6 in Docker, with the container named n8n; use your own container name in the docker commands. On n8n Cloud, the editor and Executions steps are the same, but the docker commands in Checks 2 to 5 need shell access to the server, so skip those.

This guide is published by Watchgoose, a monitor for scheduled jobs and workflows. Everything before the section on preventing the next silent failure works without it.

Table of contents

First, pin down the symptom

"Not triggering" covers four different problems, and each one has different causes:

Scroll horizontally to see all columns.

What you see in ExecutionsWhat it meansStart with
No scheduled executions at allThe trigger never fired, or the runs weren't savedCheck 1, Check 2, Check 4
Executions at unexpected timesThe trigger fires on a different schedule or time zoneCheck 3
Failed executionsThe trigger fired and a node threw an errorThe failed execution's details
Successful executions, but no resultThe workflow ran and did nothingEmpty runs

If you see executions you'd expect to see but some are missing in between, read Check 4 and the scheduler stops registering first.

Check 1: Is the workflow published?

A Schedule Trigger only runs in a published workflow. In the editor, the workflow's header shows whether it's published. Manual runs with Execute workflow work whether it's published or not, which is why "it works when I click it" doesn't rule this out.

You can also ask the n8n API, which calls published workflows "active". Create a key in Settings → n8n API (the API isn't available during the n8n Cloud free trial), put it in N8N_API_KEY, set N8N_URL to your instance's address, and look up the workflow by its ID, which is the last part of the workflow's URL in the editor:

curl -s -H "X-N8N-API-KEY: $N8N_API_KEY" \
  "$N8N_URL/api/v1/workflows/jiQV6aAzu7yJmAe6" \
  | jq -r '"\(.name)  active=\(.active)"'

Nightly CRM sync  active=true

Look it up by ID rather than listing every active workflow: the list endpoint returns 100 workflows per page by default, so on a busy instance a published workflow can be missing from the first page.

If it shows active=false, publish the workflow. If it shows active=true, also check that the published version contains your latest trigger settings: n8n only applies schedule changes when you publish, so edits saved since then don't affect the running schedule.

Check 2: Did n8n start an execution?

Open Executions for the workflow and filter by status. Scheduled runs show as started by the trigger, separately from manual test runs. From the API, using the same workflow ID:

curl -s -H "X-N8N-API-KEY: $N8N_API_KEY" \
  "$N8N_URL/api/v1/executions?workflowId=jiQV6aAzu7yJmAe6&limit=5" \
  | jq -r '.data[] | "\(.id)  \(.mode)  \(.status)  \(.startedAt)"'

18  trigger  success  2026-10-15T14:01:00.043Z
17  trigger  success  2026-10-15T13:57:00.027Z
16  trigger  success  2026-10-15T13:56:00.036Z
15  trigger  success  2026-10-15T13:55:00.036Z

mode is trigger for scheduled runs, and times are UTC. This workflow runs every minute, so the gap between 13:57 and 14:01 means three runs never started. Check 4 shows why.

An empty list doesn't always mean nothing ran. n8n can be configured not to save successful executions, and it deletes old ones. On a self-hosted instance, check:

docker exec n8n printenv EXECUTIONS_DATA_SAVE_ON_SUCCESS EXECUTIONS_DATA_MAX_AGE

If EXECUTIONS_DATA_SAVE_ON_SUCCESS is none, successful runs are never saved, so missing executions prove nothing. EXECUTIONS_DATA_MAX_AGE is the number of hours n8n keeps executions; the default is 336 (14 days). The workflow's own Settings can also override whether its successful executions are saved.

Check 3: Is the schedule what you think it is?

Open the Schedule Trigger node and read the rule again. Then check the time zone and, for interval rules, which clock times they actually run at.

n8n runs schedules in the workflow's time zone, which defaults to the instance's. On self-hosted n8n, that comes from GENERIC_TIMEZONE:

docker exec n8n printenv GENERIC_TIMEZONE

Europe/London

No output means the variable isn't set, and n8n 2.43.6 then uses its built-in default, America/New_York. Each workflow can override the time zone in Workflow menu → Settings → Timezone. On n8n Cloud, the instance time zone is set in the admin dashboard.

Interval rules don't necessarily run at the minute you published. In n8n 2.43.6, "every 2 hours" runs on even clock hours (00, 02, 04 and so on), at the minute in Trigger at Minute or, if that's empty, at a minute n8n picks for the workflow. Hour intervals that don't divide the day evenly, such as every 5 hours, and day or week intervals count runs from a stored last run; when you change the rule and publish, n8n clears that and counts from the next run, so the days or hours they land on can move. Month intervals that divide the year, such as every 3 months, stay on fixed calendar months. n8n's documentation describes interval timing differently, so trust the start times in Executions over the docs. If runs must happen at fixed clock times, set the hour and minute, or use Custom (Cron).

With Custom (Cron), n8n takes the standard five fields, optionally with a sixth seconds field at the start. 0 6 * * * is 06:00 every day. If n8n can't parse the expression, the node reports Invalid cron expression and the workflow won't schedule. To check what a five-field expression means, paste it into our cron expression tester, and see Crontab Syntax, Examples, and Why Cron Jobs Fail Silently for the field rules. The tester only accepts five fields. Leave a six-field expression as it is in n8n: removing the seconds field changes what it means, so */10 * * * * * (every 10 seconds) would become * * * * * (every minute).

Check 4: Was n8n running at the scheduled time?

n8n keeps the schedule in memory while it runs. If the instance is stopped, restarting or upgrading at the scheduled time, that run is skipped. By default n8n doesn't run it later when it comes back.

n8n 2.43 also ships a newer scheduler that can run a missed execution later, controlled by the Schedule Trigger's If Execution Is Missed setting. In 2.43.6 it's a preview, off unless the instance sets N8N_SCHEDULER_ENABLED, and the setting has no effect without it. Unless you've turned it on and tested it on your version, assume missed runs are skipped.

On self-hosted Docker, compare the container's start time with the missed run:

docker inspect -f '{{.State.StartedAt}}' n8n

2026-10-15T14:00:18.908885187Z

That's the container behind the gap in Check 2. We stopped it at 13:57:48 and it started again at 14:00:18. The 13:58, 13:59 and 14:00 runs never happened, and in our test n8n carried on with the 14:01 run. A start time just after a missed run means the instance was down or restarting. Also check the host's uptime, OOM-killer messages (journalctl -k | grep -i oom), and any automatic image updates that restart the container overnight.

Check 5: What do the logs say?

docker logs --since 24h n8n 2>&1 | grep -i -E "error|activat|schedul"

Lines worth acting on include activation errors for your workflow and messages like this one, which means an error workflow couldn't run (see below):

Calling Error Workflow for "jiQV6aAzu7yJmAe6". Workflow "Gmv8j3oxCsA8XALZ" is not active and cannot be executed

If the default output shows nothing useful, set the environment variable N8N_LOG_LEVEL=debug, restart n8n, and search again around the next scheduled time. Set it back afterwards; debug logging is verbose.

Common causes and fixes

The workflow isn't published, or the change wasn't

This is the cause we'd check first. Publish again after any trigger change, then confirm with Check 1.

The cron expression is invalid

A typo or an unsupported character in a Custom (Cron) rule stops the trigger from scheduling at all, and the node shows Invalid cron expression. Check that it has five fields, or six when the first one is seconds, fix the typo, and publish again.

Interval rules run at unexpected times

"Every 2 hours" runs at clock hours and a minute you may not have chosen, and some longer intervals move after you change the rule (Check 3). Use fixed hours and minutes or a cron expression for clock-time schedules.

The time zone is wrong

The workflow runs, but at 07:00 instead of 06:00, or at a UTC time when you meant local time. Daylight saving changes move it again twice a year. Set GENERIC_TIMEZONE on self-hosted instances and the workflow time zone explicitly for anything time-sensitive.

n8n was down when the run was due

Restarts, upgrades, crashes and memory kills all skip whatever was scheduled during the gap. So does a laptop that goes to sleep with n8n running in Docker Desktop. Schedule upgrades away from important runs, give the container enough memory, and make sure something outside n8n notices a missed run.

The scheduler stops registering the workflow

Users have reported published workflows whose schedule stops firing after running for a while, with no failed executions and nothing in the logs, while manual runs still work. Examples include an n8n Cloud report on the community forum, a queue-mode Kubernetes report and GitHub issue #31326. The workarounds people report are unpublishing and republishing the workflow, or restarting the instance; neither is guaranteed. Upgrade to the latest n8n release, and monitor from outside n8n so you hear about the next occurrence within one cycle.

The workflow runs but does nothing

When a node returns no items, the nodes after it don't run, and the execution still ends as successful. An expired credential or a changed API can cause this: the search returns nothing, nothing is written, and Executions shows green. Some nodes return an item even when there's nothing useful in it, such as an empty list or a count of zero, and then the rest of the workflow carries on with bad data. In both cases, add a check that throws an error when the result is wrong, for example an If node that leads to a Stop and Error node. When the node returns no items, that check is skipped along with everything else, so first turn on Always Output Data in the Settings tab of the node that fetches the data. The node then passes on one empty item instead of nothing, and the check runs. Make the check fail on an empty item, and on a count of zero on a day there should always be some.

Executions were never saved

This one looks like a scheduling problem. With EXECUTIONS_DATA_SAVE_ON_SUCCESS=none, or a workflow set not to save successful executions, successful runs leave no trace in Executions. Save at least successful scheduled runs while you investigate.

Why your error workflow didn't warn you

An error workflow, built with the Error Trigger node and selected in another workflow's Settings → Error workflow, runs when an automatic execution of that workflow fails, and when n8n can't activate the workflow's trigger, for example at startup. It doesn't run in these cases:

  • When the trigger never fired. There's no execution, so nothing fails. That covers an unpublished workflow, a wrong schedule, an instance that was down and a scheduler that lost track of the workflow.
  • When the run succeeded with no output (see empty runs).
  • When you ran the workflow by hand. Error workflows only run for automatic executions, so you can't test them with Execute workflow.
  • When the error workflow itself isn't published. n8n's documentation says an error workflow doesn't need to be published, but in our test on 2.43.6 it did: n8n logged the "is not active and cannot be executed" message shown in Check 5, and the error workflow only ran after we published it. Publish your error workflow.
  • When n8n is down. A workflow running inside the instance can't report that the instance stopped.

For the first and last cases you need something outside n8n that expects each run.

Preventing the next silent failure

The reliable fix is to have the workflow report back when it finishes, and to have something outside n8n waiting for that report. In Watchgoose, each workflow gets a check with its own ping URL. Add an HTTP Request node at the very end of the workflow, after the work and after any checks that throw an error on a bad result:

Parameters tab:  Method POST, URL https://watchgoose.com/ping/your-uuid-here, Options → Timeout 10000
Settings tab:    Retry On Fail on (Max Tries 3), On Error: Continue, Execute Once on

Retry On Fail rides out a brief network problem. On Error: Continue means the workflow still succeeds if Watchgoose can't be reached. Execute Once makes the node send one ping each time it runs, however many items reach it. It can still run more than once in an execution, so put the ping after any Loop Over Items has finished, and if the workflow branches, join the branches with a Merge node before the ping. If a node before it returns no items, the ping doesn't run, so that kind of empty run shows up in Watchgoose as a missed run. A node that returns an item with an empty list or a zero count still reaches the ping, so it needs the check described under empty runs.

Give the Watchgoose check the same schedule and time zone as the trigger: a Schedule Trigger "every day at 06:00" in Europe/London becomes the cron expression 0 6 * * * with the Europe/London time zone. Watchgoose cron schedules have five fields. If an n8n schedule's seconds field is a single number, as in 0 30 6 * * 1-5, give the check the five fields after it (30 6 * * 1-5). If it runs more than once a minute, as in */10 * * * * *, Watchgoose can't expect each run, because its shortest period is one minute; a one-minute period check still tells you when the pings stop. Set the grace time to how long the workflow normally takes plus a margin, for example 30 minutes for a ten-minute sync. After the first successful ping, Watchgoose expects the next one on schedule. If it doesn't arrive within the grace time, for any of the reasons above, Watchgoose alerts you by email, Slack, webhook or another channel. To report failures straight away instead of waiting for the grace time, send a request to https://watchgoose.com/ping/your-uuid-here/fail from an error workflow; to see how long each run takes and catch runs that hang, send https://watchgoose.com/ping/your-uuid-here/start at the beginning. The signaling failures and measuring run time docs cover both.

The free plan covers 10 checks without a credit card. A success ping proves the workflow reached its last node; put your own checks before it so it also means the result was right.

Frequently asked questions

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

Manual runs work in unpublished workflows; the Schedule Trigger doesn't. Check that the workflow is published and that the published version contains your latest trigger settings. If it is, check the time zone, whether the instance was running at the scheduled time, and the Executions list for runs that happened at a different time.

Does n8n run scheduled workflows it missed while it was down?

Not by default. n8n skips any scheduled run that was due while the instance was stopped or restarting and continues with the next one. If a run must not be missed, monitor it from outside n8n so you know when it didn't happen.

Why does the Error Trigger not catch a workflow that didn't run?

The Error Trigger runs when an automatic execution fails or the trigger can't be activated. If the schedule simply didn't fire, there's no execution and no error. It also doesn't run for manual executions, or when the n8n instance itself is down.

Why is my n8n Schedule Trigger not firing?

The most common reasons are an unpublished workflow or an unpublished trigger change, an invalid cron expression, and an instance that was down at the scheduled time. If the workflow is published and n8n was running, check Executions for runs at a different time, which points to the time zone.

Why does my n8n schedule run at the wrong time?

Usually the time zone: the workflow uses its own time zone setting, or the instance's GENERIC_TIMEZONE. If that isn't set, n8n 2.43.6 defaults to America/New_York. Interval rules can also surprise you: in n8n 2.43.6, "every 2 hours" runs on even clock hours at a fixed minute, not two hours after you published.

Conclusion

Start with the publish state and the time zone, then compare the gaps in Executions with the container's start time. If all three check out, the scheduler may have lost track of the workflow; republish it or restart n8n. The error workflow won't report any of these, so the workflows you depend on need a check outside n8n.

References

Monitor your first n8n workflow