n8n Workflow Stopped Running With No Error
Check Active, then the executions list, then whether n8n itself is alive. Most reports end at the first step.
Open the workflow and look at the Active toggle in the top right. A workflow that was saved but never activated runs in the editor and nowhere else, and this accounts for more of these reports than everything else combined.
If it is active, open the Executions tab and filter to that workflow. Executions present means it is running and something inside it is wrong. No executions means it is not being triggered.
The webhook URL trap
Every n8n Webhook node has two URLs, a test URL and a production URL, and they are not interchangeable.
The test URL only accepts requests while you have the editor open and have clicked Listen for test event. It stops working the moment you close the tab. If you copied a URL from the node during development and put it in Stripe or a partner's dashboard, that integration worked while you were testing and has been dead ever since.
Check what the sender has registered, not what you think you gave them. The words webhook-test in the path are the whole diagnosis.
If it is active and not triggering
For schedule triggers, confirm the timezone. n8n uses GENERIC_TIMEZONE for schedule evaluation, and a container defaulting to UTC while you reason in local time produces a job that runs, just not when you are watching.
For polling triggers such as Gmail or a database node, the usual cause is an expired credential. n8n surfaces this in the execution as an error, so check Executions filtered to failed rather than assuming there is nothing there.
For webhook triggers on a self-hosted instance, confirm WEBHOOK_URL is set to your public address. If it is not, n8n generates URLs against localhost and the ones you copied are unreachable from outside.
Check that n8n itself is up
Everything above assumes n8n is running. If the container stopped, the database it depends on failed, or the disk filled, no workflow runs and no error workflow fires either, because your error handling also lives inside n8n.
If you run queue mode, the main process and the workers fail independently. A healthy main process with every worker down means executions are queued and never run, and the UI shows them sitting in a waiting state rather than reporting an error.
The evidence may have been deleted
Self-hosted n8n prunes execution history according to EXECUTIONS_DATA_MAX_AGE, which defaults to 336 hours. If you are investigating something from three weeks ago, the executions are gone and their absence is not evidence that nothing ran.
Why nothing told you
n8n's Error Trigger is good and it only fires when a workflow runs and fails. A workflow that is inactive, untriggered, or sitting in a stopped container never runs, so there is nothing for it to catch.
The gap is closed by something outside n8n watching for the absence of a completion signal, which is what SensaCat does. The full setup, including an error workflow, is in how to monitor n8n workflows.