Ran Fine
The active flag records that a workflow is registered, not that its trigger is still scheduling runs. When the two disagree, the interface reads the database and shows a green toggle while nothing is being scheduled at all.
This failure has no error, no failed execution and no alert. There is nothing to catch, because nothing ran. The workflow list shows active, the last execution looks normal, and the only evidence is a gap in a history that n8n will eventually delete on its own retention schedule.
Most people find it the way the failure is designed to be found: somebody downstream asks where the data went.
active actually mean?It means the workflow is marked for activation in the database. It does not mean a timer is currently counting down anywhere.
Activation has two halves. The flag is persisted, and the trigger is registered in the memory of the process that owns scheduling. The user interface only reads the first half. Any situation that leaves the flag set while the in-memory registration is missing produces a workflow that looks live and is not.
The database still says active because nobody changed it. The schedule that used to exist in memory does not, and nothing reconciles the two afterwards.
There is nothing in the execution log to see. The last execution before the restart completed normally, so the most recent record is a healthy one. The failure is everything that should have come after it.
A schedule trigger fires on a window. A window that passes while nothing is scheduling it is gone, and nothing is backfilled when the process returns.
This is why the damage is measured in hours rather than in runs. A ten-minute workflow that stops overnight does not owe you a hundred queued executions in the morning. It simply never did that work.
In queue mode the main process enqueues work and workers execute it. Monitoring usually watches the workers, because that is where errors happen.
If the half that enqueues is the half that stopped, the queue is not full of failures. It is empty. Every dashboard built on counting failed jobs shows a clean board, correctly, because there is nothing to count.
A workflow triggered by a webhook may sit idle for days without anything being wrong. A scheduled workflow idle for the same period is broken.
From the outside both are "active, no recent executions". Any check that treats silence as failure without first asking whether the workflow is supposed to start on its own will alert on every webhook you own, and an alert that is usually wrong gets muted within a week.
Because an execution row is only written when a run starts. A run that never started produces no row, no status, and nothing for an error workflow to fire on.
Error workflows are triggered by executions that fail. That is a genuine feature and it covers a real class of problem. It cannot cover this one, because the thing that went wrong is the absence of an execution, and an absence cannot raise an event.
The same reasoning applies to anything you build inside n8n to watch n8n. A watcher that is itself a workflow shares the scheduler it is supposed to be watching. When that scheduler stops, the watcher stops too, and its silence looks exactly like everything being fine.
Compare the time since each workflow's last successful execution against how often its own schedule says it should run, and do the comparison from outside the instance through the public API with a read-only key.
Three details decide whether this works in practice.
The threshold has to come from the workflow, not from you. One global "alert after two hours" either shouts about every ten-minute workflow the moment a run is slightly late, or hides a daily workflow that has been dead since Tuesday. Read the interval out of the trigger and derive the tolerance from it.
Only judge workflows that start themselves. Schedule, cron and interval triggers are expected to run unprompted. Webhook-driven ones are not, and including them is how the check earns itself a mute rule.
No history is unknown, not broken. n8n prunes execution data on a retention schedule, so a workflow with no visible executions may have run perfectly all week. Treating pruned history as "never ran" alerts on everything the moment the retention window rolls over, which is the fastest way to make a monitor worthless.
invoice-sync last run 4m ago schedule every 10m ok lead-router last run 3h 12m schedule every 15m STALE weekly-report last run 6d 2h schedule weekly ok contact-form last run 9d webhook not judged
Not on their own. n8n's Prometheus metrics describe the health of the process, and a healthy process with nothing scheduled looks identical to a healthy process doing its job.
This is not a theoretical objection. In September 2026 I reported it against selfhost-ai, an open-source stack that ships n8n with a Grafana dashboard. Twenty panels covered process health and none covered whether workflows actually ran, so a scheduled workflow could stop entirely while every panel stayed green.
The maintainer shipped the fix in two days, adding executions by outcome, executions per workflow, time since the last successful execution per active workflow, and alert rules for stalled workflows and workflows with no recorded success. On the way he found that Prometheus had never been scraping the workers at all — a monitoring gap that had itself been invisible.
With the event-bus metrics enabled and those panels in place, the stopped-workflow case is covered. What remains uncovered is the run that starts, finishes, reports success and produces nothing, which is a different failure and needs output rather than status.
I do fixed-fee reliability audits for n8n and Make automations — one week, a written report naming which of your workflows fail silently today and what breaks first.
There is a full sample, run against my own production stack and published unedited, including the five silent failures it found there.
Read the sample auditThe detection method described here is implemented and open source: github.com/moneywithjjcom-del/ranfine-. It reads execution history through the public API with a read-only key, adds no nodes to any workflow and runs nothing inside the instance.
The selfhost-ai exchange is public and linked above, including the maintainer's own account of what the dashboard did and did not cover. The behaviour of the active flag and the absence of backfill for missed windows are described from self-hosted 2.x and are consistent with what other operators report; I have not read the scheduler source, and where the exact mechanism matters to you, verify it against your own version rather than taking this page's word for it.
Related: four ways an n8n workflow reports success and does nothing, which covers the case where the run happens and the output does not, and how to catch a workflow that runs but produces the wrong output, which covers the case where the output arrives and is wrong.