Your n8n Schedule Trigger didn't fire, and nothing told you.

Short answer

Check four things in this order: the workflow is published, the version you published has the schedule you think it has, the timezone n8n uses is the one you mean, and the instance was up at the scheduled time. Then make the workflow prove it ran: give it a watch in Did It Run? and end the workflow with an HTTP Request node that pings the watch. If the trigger doesn't fire, no ping arrives and you get a missed alert at the scheduled time plus your grace window, from outside your n8n instance. Start free (3 watches, no credit card).

Check-ins are by ping URL today, with /start and /fail variants. Email check-ins are coming soon.

Why a Schedule Trigger doesn't fire

• The workflow isn't published. n8n's docs say that if a workflow uses the Schedule node as a trigger, you must save and publish it (n8n Docs, Schedule Trigger). Running it from the editor is a manual test; it doesn't start the schedule. From n8n 2.0, Publish and Unpublish replaced the old Activate/Deactivate toggle (n8n Docs, v2.0 breaking changes).
• Your edits are still a draft. n8n autosaves edits, but production runs use the published version, not your latest edits. Edits stay in draft until you publish again (n8n Docs, Save and publish workflows). A new schedule you set and never published isn't the one running.
• Publishing only partly worked. If at least one trigger failed to activate, the button shows Published, partial; if none activated, Failed to publish, and the workflow isn't running (n8n Docs, Save and publish workflows).
• You changed the interval or a variable after publishing. n8n only picks up a new trigger interval, or a new value for a variable used in the schedule, when the workflow is published again. n8n's troubleshooting page says to unpublish and publish a new version (n8n Docs, Schedule Trigger common issues).
• It fired, at a different time than you expected. The node uses the workflow's timezone if one is set, otherwise the instance timezone. Self-hosted n8n defaults to America/New_York (set GENERIC_TIMEZONE to change it); n8n Cloud tries to detect the owner's timezone at sign-up and falls back to GMT (n8n Docs, Schedule Trigger).
• The day doesn't exist that month. With the Months interval, if a month doesn't have the day you picked, the node doesn't trigger. Pick the 30th and it won't run in February (n8n Docs, Schedule Trigger).
• The instance was down at the scheduled time. On the older in-memory scheduler, a run whose time passed while the instance was stopped is skipped, not caught up. On the durable scheduler (on by default from n8n 2.45.0), a run missed during downtime still fires late if it's within its grace period, which defaults to one minute. Past that, the node's If Execution Is Missed setting decides, and the default, Don't Run Missed Executions, discards it (n8n Docs, Durable scheduler; Schedule Trigger node options).
• "Every 15 minutes" isn't on the quarter hour any more. From n8n 2.45.0, with the durable scheduler, Seconds and Minutes intervals run at uniform intervals measured from when the workflow was published, not on clock boundaries. Custom (Cron) intervals keep their timing (n8n Docs, Schedule Trigger).

In every one of these cases there's no failed execution, so an error workflow can't help: n8n's error workflow runs when an execution fails (n8n Docs, Error handling).

Step 1: confirm what's live

1. On the Workflows page, check that the workflow card shows the published indicator. In the editor, the Publish button should read Published, not Published, partial or Failed to publish. If it shows Published, has changes, your latest edits (including a new schedule) aren't live.
2. Open the Schedule Trigger and read the interval or cron expression in the version you published. In a custom cron expression, an optional sixth field at the start is seconds.
3. Open Workflow settings and check Timezone. If it's not set, find out the instance timezone (GENERIC_TIMEZONE when self-hosting; the Cloud console on n8n Cloud).
4. Open the workflow's executions and compare the times with the schedule. A gap where a run should be, with no failed execution, is a trigger that didn't fire.

Step 2: decide what happens to runs missed during downtime

If your self-hosted instance restarts or goes down (deploys, upgrades, an out-of-memory kill), decide what you want for runs it missed. On n8n 2.36 or later with the durable scheduler, a Schedule Trigger node added from that version on has If Execution Is Missed and Missed Execution Grace Period (Seconds) in its Settings tab. Run the Most Recent Missed Execution runs one catch-up run instead of discarding it. If you set N8N_SCHEDULER_ENABLED=false, the in-memory scheduler never runs missed executions (n8n Docs, Schedule Trigger node options).

Catch-up helps, but it still doesn't tell anyone that a run was late or skipped.

Step 3: add a heartbeat so a missed run reaches you

1. Create a watch in Did It Run? with the same schedule as the Schedule Trigger, in the same timezone, with a grace window that covers the workflow's normal run time. Watch schedules are clock-aligned, so for a Minutes interval measured from publish time (n8n 2.45.0 and later), set the grace window to one full interval (for "every 15 minutes", 15 minutes of grace).
2. Add an HTTP Request node as the last step of the workflow: POST to the watch's ping URL, with the number of items processed in the body:

{ "items": {{ $input.all().length }}, "text": "run complete" }

1. Turn on Retry On Fail for that node.
2. Optional: for instant failure alerts, add an error workflow (Error Trigger → HTTP Request, POST to the ping URL with /fail appended) and select it in the workflow's settings.

Now each case is covered:

• The trigger didn't fire (unpublished, failed to publish, instance down, a missed run discarded): no ping arrives, so the run is missed at the deadline.
• The workflow ran and an execution failed: the error workflow calls /fail and you get a failed alert.
• The workflow ran, but on nothing: set Minimum item count to 1 on the watch, and a run that processed zero items raises an empty alert. See n8n workflow silently failed.

Full setup steps are in the n8n recipe.

Honest limits

• Did It Run? doesn't connect to your n8n instance, publish workflows or read your executions. It only sees the check-ins your workflow sends.
• A missed alert tells you the run didn't arrive, not why. Step 1 is how you find out which cause it was.
• If the HTTP Request node can't reach the ping URL even after retries, the run shows up as missed rather than fine, which is the safe way round.

What you'll see

• Missed: no check-in by the expected time plus grace.
• Late: an optional early warning while the run is still inside its grace window.
• Failed: the workflow called /fail.
• Empty: the check-in arrived but failed the watch's sanity check.
• Recovered: the first good run after a problem.

You get one alert when a watch changes state, not one for every run, plus a recovery notice. Free covers 3 watches with email alerts; Solo ($15/month) adds Slack, Discord and Telegram alerts and a daily roll-call digest across all your automations.