Why n8n workflows stop running
n8n alerts you when a workflow fails, but says nothing when one simply stops running. Here is why that happens, and how to detect the silence.
Last updated
n8n alerts you when a workflow errors. It says nothing when a workflow simply stops running. A schedule trigger quietly deactivates, an instance restarts and loses state, or a webhook source stops firing. No error is raised, so no alert fires and nothing appears in your logs.
Why do n8n workflows stop without an error?
An error workflow can only fire when an execution runs and fails. If the execution never starts, there is nothing to catch. Three causes account for most silent stoppages: a schedule trigger that deactivates after an instance restart, a workflow left inactive after a manual edit, and an upstream webhook source that stops sending. In all three cases n8n's own execution list simply has no new rows — which looks identical to a quiet period.
Why doesn't an n8n error workflow catch this?
Error workflows have two structural gaps. First, they fire on errors only, so they cannot detect "didn't run at all". Second, they live inside each n8n instance, so an agency running one instance per client ends up with ten separately configured monitors and no aggregate view. When the instance itself is down, the error workflow is down with it.
How do you detect a workflow that stopped running?
You need an expectation of when the workflow should have run, and something outside the instance to check it. Norvane infers the expected interval from the workflow's cron configuration where one exists, and otherwise learns it from execution history — using the median gap only when that history is regular enough to be trustworthy. When now minus the last execution exceeds the expected interval plus a grace period, that silence becomes an incident.
What happens when the whole instance is down?
Every monitored workflow on a downed instance is overdue at the same moment, which would produce one alert per workflow. Norvane suppresses those: while an instance-down incident is open, missed-run incidents for its workflows are neither opened nor alerted, and on recovery they are re-evaluated before anything is sent — because most of them self-heal.