n8n workflow stopped running: why a schedule goes quiet
The workflow is there, the last execution succeeded, and nothing has run since. No error exists, because nothing ran to produce one — the hardest failure to notice and the easiest to explain once you know where to look.
What it looks like in n8n
The execution list simply stops at a date. The newest run is green. Open the workflow and it looks finished and fine. Whatever it was feeding has been stale since that date.
- The last execution is hours or days older than the schedule interval.
- The workflow's Active toggle is off, or on but with no recent runs.
- A duplicate of the workflow exists, and only one of the two is active.
- Runs happen, but an hour off, or not on the days you expected.
Common root causes
A schedule that never fires has a small number of usual explanations.
The workflow was deactivated
Saving during an edit, importing a copy, or testing a change can leave the workflow inactive. Manual test runs still work, which makes it look healthy.
Timezone mismatch on the schedule trigger
The instance timezone, the workflow timezone and the cron expression disagree. The run fires at 08:30 somewhere else, or skips the day entirely at a DST boundary.
A cron expression that means something else
A field in the wrong position, or a day-of-week and day-of-month combination that almost never both match.
The n8n instance was restarted or moved
After a container restart, a migration or an out-of-memory kill, workflows can come back inactive, and queue workers can come back not processing.
A webhook caller stopped calling
For webhook-triggered workflows nothing is wrong on your side at all. The upstream system changed URL, lost its credential, or was switched off.
The polling trigger lost its credential
A poll trigger whose credential was revoked can stop producing executions without leaving an error in the execution list.
How to check it manually today
Five minutes of checks will identify most cases.
Check Active, then check for duplicates
Confirm the workflow is active — and that you are looking at the copy that is supposed to be active. Search the workflow name for near-identical siblings.
Read the trigger node against the instance timezone
Compare the cron expression and the workflow timezone setting with the instance timezone, then work out when the next run should be in your own local time.
Compare the last execution against the interval
If the schedule is hourly and the newest run is from yesterday, you already have your answer: the problem is that nothing ran, not that something failed.
Run it manually once
A manual run that works proves the logic is fine and points the investigation at the trigger rather than the body of the workflow.
Check the instance itself
Look at the n8n logs or container status around the date the runs stopped. A restart at that moment explains a lot.
How OutcomeGuard detects it
A missing run is absence of evidence, which is why it needs a tool that knows what to expect.
- OutcomeGuard parses cron and interval triggers, including their timezone, and knows when the next run was due.
- When the deadline plus a grace period passes with no execution, it raises MISSED_RUN with the expected time and the actual last run as evidence.
- For triggers without a declared schedule it learns the observed cadence instead, and notices when a steady rhythm stops.
- It hashes the workflow definition, so a deactivation or an edit shows up as CONFIG_DRIFT at the moment it happens.
- If the instance itself cannot be reached, the status is UNKNOWN rather than a guess about your workflows.
Check which schedules are already overdue
The free health check reads every workflow's trigger and recent runs, and lists the schedules that should have fired and did not.