When an n8n schedule trigger is not working, the workflow can look active and still never run. Three of my monthly workflows did that for up to 7 weeks. n8n showed them as on the whole time, no run ever started, nothing failed, and my error workflow had nothing to catch. Now a daily watchdog workflow checks every schedule and emails me when one goes quiet. A generator below builds yours.
This post contains affiliate links. If you sign up through one, I earn a commission at no extra cost to you. I only point to tools I actually use or would recommend.
I figured the sweep was just behind
I have way too many workflows to notice on my own when one stops, so I rely on error handling. If something breaks, I get an email. That was the whole plan, and I trusted it.
Then on September 8, I sat down to write up some of my builds and opened my builds table, the running list of everything I’ve made. It was missing stuff. A monthly sweep is supposed to keep it current, so I told Claude Code, “I guess it’s behind or isn’t working well,” and asked it to scan the table before we started the post.
Claude ran the sweep by hand and it worked fine in 10 seconds. So it went looking for why it hadn’t run on its own on September 1. The n8n server was healthy, with 244 scheduled runs that day. That narrowed it to monthly schedules, and there it was. Three of my monthly workflows had never run once:
- Cross-Promo Sweep, live since July 19. Missed August 1 and September 1.
- Builds Table Sweep, live since August 9. Missed September 2.
- Studio Content Sweep, live since August 20. Missed September 1.
All three showed as active the whole time. I’m sitting here thinking everything is running, and it’s not even firing. I was mad, and I lost trust in my systems. I only found out because I was tweaking something else and Claude noticed.
Why is my n8n schedule trigger not working?
The usual reasons are in n8n’s own docs: the schedule was changed but not republished, the timezone is off, or the cron expression is invalid. The first one catches you without an error. n8n says a changed trigger interval doesn’t take effect until you unpublish the workflow and publish a new version, and the schedule starts from the moment you publish.
| What you see | Likely cause | Fix, per n8n’s docs |
|---|---|---|
| Workflow is on, new schedule never kicks in | Interval changed without republishing | Unpublish, then publish a new version |
| It runs, just at the wrong hour | Timezone | Set the timezone in the workflow’s settings, or the instance timezone |
| An “Invalid cron expression” error | Custom cron n8n can’t read | Fix the expression and test it without the seconds column |
As for mine, I don’t know. On September 8, Claude blamed a blank months value in the schedule, and I believed it. It filled in the value and we moved on. While I was writing this post, Claude checked again and ran the code n8n uses to load a workflow before it runs. n8n fills in that blank on its own. So that wasn’t it, and the fix didn’t fix anything.
None of the three has hit a due date since. The first real proof comes October 1 and 2. That’s a strange thing to admit in a post about a watchdog, but it’s also the best argument for one. When you can’t explain why something stopped, the only thing left is catching it the next time it does.
What does a schedule watchdog do?
A schedule watchdog is a workflow that checks whether your other scheduled workflows actually ran. An error workflow tells you when a run fails. A watchdog tells you when a run should have happened and didn’t, which is the one thing an error workflow can’t see.
Mine runs every morning at 7 and does four jobs:
1. Reads every workflow through the n8n API and finds the ones with a schedule. 2. Works out how often each one should run from its schedule rule, so it knows what late means for a daily workflow versus a monthly one. 3. Checks the last run for each workflow, one at a time, and compares it to its schedule. A workflow that’s gone more than twice its normal gap without a run is overdue. 4. Emails me only when something newly goes bad, plus a Monday recap of anything still open. If everything’s fine, it says nothing.
| Error workflow | Schedule watchdog | |
|---|---|---|
| Catches | A run that started and failed | A run that never started |
| Fires | The moment a run fails | Once a day, on its own schedule |
| Needs | A setting on every workflow | Nothing on the workflows it watches |
| How fast on a monthly workflow | Never, since nothing fails | About 60 days, since overdue means twice the normal gap |
I have both now. The n8n error workflow post covers the failure half.
Who is a schedule watchdog for?
It’s for you if you run more scheduled workflows than you’d ever notice stopping. Monthly and weekly workflows are the ones to worry about, because a missing run doesn’t show up for weeks.
Skip it if you have a handful of workflows and you’d notice right away if one stopped. You’re already the watchdog.
What do you need to build a schedule watchdog?
- n8n with API access. The watchdog reads your workflows through the n8n API, so you need an API key. Mine is self-hosted on a Hostinger VPS.
- Somewhere to keep notes. I use Airtable. It’s how the watchdog remembers, and the next section explains why it has to.
- Somewhere to send the alert. I use Gmail. Slack, Telegram and Discord work too.
- Claude Code, optional. Claude built mine, and the generator writes a skill for it. The paste-in prompt works in any chat.
How does a schedule watchdog work?
It works by remembering. Every morning it writes down when each workflow last ran, and it keeps that date even after n8n forgets it.
n8n doesn’t hold on to run history forever. Mine keeps about the newest 5,000 runs, and at roughly 1,850 runs a day, that’s about 2.5 days. So by the time a monthly workflow is late, its last real run is long gone from n8n. Without its own notes, the watchdog would have no way to tell “ran on the 1st” from “never ran.”
My notes live in one Airtable table with a row per scheduled workflow. Each row has the workflow’s name, its schedule, when it was last seen running, and one of these:
- OK. It ran on time.
- Watching. It’s new to the watchdog and hasn’t had a chance to run yet, so it isn’t judged.
- Overdue. No run in more than twice its normal gap.
- Broken. The schedule itself can’t fire.
- Deactivated. I switched it off. It’s marked, not deleted, so turning something off on purpose doesn’t set off an alarm.
As of this morning it’s watching 84 schedules. 71 are OK, 1 is switched off, and 12 are Watching. Those 12 are monthly, quarterly, 90-day and yearly workflows it hasn’t seen run yet, and the monthly ones get their first real check on October 1 and 2.
Get the generator
The generator asks where your n8n runs, how your schedules get built, where you want alerts, and where the watchdog should keep its notes. Then it writes you a prompt to paste into Claude or ChatGPT, a skill for Claude Code, or both.
If AI or the API builds your workflows, it also gives you a short prompt to check your schedules today and see whether each one has run when it should have, so you don’t have to wait for a watchdog. Paste the prompt into a chat, or save the skill as SKILL.md in its own folder under ~/.claude/skills/.
What it doesn’t do
It hasn’t proven itself yet. The watchdog is less than a week old, and it hasn’t caught a real problem. My trust was lost on September 8, and one week of quiet emails doesn’t give it back.
Its first real email, on September 14, said 10 workflows were overdue. Nine of them were fine. It was only looking at the newest 250 runs across all of n8n, which on my server covers about 3 hours, so every healthy daily workflow that ran earlier than that looked late. It also read every custom schedule as weekly, it checked once a week against history that only lasts 2.5 days, and it had no timezone set, so “7am” ran at midnight. Claude fixed all four that day. The tenth was a workflow I’d stopped using on purpose, so that wasn’t a catch either.
It’s slow on monthly workflows. Overdue means no run in twice the normal gap, and for a monthly workflow that’s 60 days. If it had been watching the Cross-Promo Sweep from July 19, it would have flagged it around September 17. I found it by accident on September 8. It also can’t tell me why something stopped.
It runs on the same n8n server as everything it watches. If that server goes down, the watchdog goes quiet along with the rest of them.
It doesn’t fix anything. When something’s overdue, I still have to look at that workflow’s own runs before I believe the alert.
Frequently asked questions
Why is my n8n schedule trigger not running?
The most common silent cause is a schedule change that was never republished. n8n’s docs say a changed interval doesn’t take effect until you unpublish the workflow and publish a new version. Also check the timezone setting if it runs at the wrong hour.
Will an n8n error workflow tell me if a schedule didn’t run?
No. An error workflow only runs when an execution fails. A schedule that never fires never starts an execution, so there’s nothing to fail and nothing to report.
How do I check if a scheduled n8n workflow ran?
Look at the workflow’s Executions list for a run at the time it was due. For monthly workflows, check soon after the due date, since n8n prunes old runs. Mine keeps about 2.5 days of history.
Why did my monthly n8n workflow not run?
Start by checking whether the schedule was changed after the workflow was published, since that needs an unpublish and a new publish. Then look at its Executions list right after the due date. If it never ran and nothing looks wrong, you’re where I am, and a watchdog is how you catch the next miss.
How long does n8n keep execution history?
It depends on your instance’s pruning settings. Mine keeps about the newest 5,000 runs, which is roughly 2.5 days on my server. That’s why a watchdog needs its own notes to judge monthly workflows.
Can a watchdog run on the same n8n server it watches?
Yes, and mine does. The catch is that if the server goes down, the watchdog stops too, so it won’t warn you about a full outage.
Try it yourself
An n8n schedule trigger that isn’t working can look active for weeks, and a daily watchdog that remembers each workflow’s last run is how you find out without stumbling on it by accident.
Start with the check-your-schedules prompt from the generator above, and republish anything whose schedule you changed. Then build the watchdog and expect a few false alarms on its first run. If you haven’t set up the failure half yet, the n8n error workflow post walks through it, and the Claude Code to-do list is where my alerts go to get worked on.
A tool I built
Giveaway Widget
Host a real giveaway on your own site. Verified entries, bonus entries for referrals and shares, and a one click winner draw.
Start your giveaway →I run an affiliate program on the tools I build. Approved affiliates earn 20% on what their referrals pay, for up to a year. US only for now. See the program →
Related reading
- How I Set Up an n8n Error Workflow So I Stop Finding Out Days Later
- How I Stopped Rebuilding Things I’d Already Built
- The Claude Code To-Do List That Works Before I Do
Subscribe if you haven’t already. More builds are on the way, including the ones that broke first. Go forth and automate the boring stuff.
