n8n workflow not executing: a diagnostic checklist

Last updated: September 12, 2026

Open the workflow's Executions tab. If it is empty, the workflow has never executed in production and the problem is configuration. If it shows a column of executions that ends on a certain date, the workflow used to work and something changed on or around that date — jump to the second half of this page, and read the page on workflows that stopped running for the deeper version.

1. 1The workflow is not active. Manual test runs work with an inactive workflow; production triggers do not. Check the toggle in the top bar.
2. 2You are calling the test webhook URL. The Webhook node has a Test URL that only listens while you are clicking “Listen for test event” in the editor, and a Production URL that works when the workflow is active. Callers configured with the test URL get nothing once you leave the editor.
3. 3The cron expression does not mean what it looks like. Five fields, in the order minute, hour, day of month, month, day of week. “0 9 * * 1” is Mondays at 09:00, not every weekday. Use the Schedule Trigger's interval mode unless you need cron.
4. 4The timezone is not yours. The instance timezone (GENERIC_TIMEZONE), the workflow's own timezone setting and the cron expression are three separate things. 09:00 in the workflow's timezone may be 00:00 in yours.
5. 5n8n Cloud execution limit reached. Cloud plans have monthly execution quotas; when a plan is over its limit, workflows can stop executing until the period resets or the plan changes. Check usage in the Cloud dashboard.
6. 6Behind a reverse proxy, WEBHOOK_URL is wrong. Self-hosted n8n builds webhook URLs from WEBHOOK_URL; if it points at an internal address or the wrong scheme, the URL you copied is not reachable from outside.
7. 7Queue mode without workers. In queue mode the main process only schedules; if no worker is connected (or the Redis connection is broken), executions are queued and nothing runs.
8. 8The polling trigger's credential is invalid. Polling triggers (Gmail, IMAP, Google Sheets, Airtable and others) fail quietly on an expired or under-scoped credential; some record no execution at all.

1. 1Deactivated during an edit. Saving from the editor, importing a copy or toggling to test can leave the workflow inactive. Manual runs still pass, so it looks healthy.
2. 2A duplicate. Someone copied the workflow to test a change; the copy is inactive and the original is the one you are looking at, or the other way round. Search by name for siblings.
3. 3An instance restart or migration. Containers restarted after an out-of-memory kill, a version upgrade or a host move can bring workflows back inactive, or bring the main process back without its workers.
4. 4The caller stopped. For webhook-triggered workflows nothing is wrong on your side: the upstream system changed its URL, lost its credential, or was switched off.
5. 5A credential expired. OAuth tokens and API keys used by polling triggers expire; the trigger stops producing executions and n8n has no error to show because no execution started.
6. 6Daylight-saving time. A cron that runs at 02:30 local time can skip or double on the changeover night; a workflow timezone different from the instance's can shift every run by an hour twice a year.

The last four leave no error anywhere in n8n, because the failure is the absence of an execution. That is why they are found days later by whoever was waiting for the data — and why monitoring them means knowing when a run was due, not waiting for something to go red.

1. 1Confirm Active is on, then search the workflow list for a sibling with the same name.
2. 2Run it manually once. If the manual run passes, the workflow body is fine and the trigger is the problem.
3. 3For webhooks, call the Production URL with curl while the workflow is active and watch the Executions tab.
4. 4For schedules, write down the cron, the workflow timezone and the instance timezone, and compute the next run in your local time.
5. 5Compare the newest execution with the interval. If the gap is larger than the interval plus a little slack, nothing ran; check the instance log around the last execution's time for a restart.

• It parses cron and interval triggers, including the timezone, and knows when each run was due; a deadline plus grace that passes without an execution becomes a Missed run finding with the expected time and the last actual run as evidence.
• For triggers without a declared schedule (webhooks, polling) it learns the observed rhythm and reports when a workflow that used to fire every hour has been quiet for far longer than its longest observed gap.
• It hashes each workflow definition, so a deactivation or an edit shows up as Configuration drift at the moment it happens.
• If the instance itself cannot be reached, it says Unknown and does not guess.
• It reads through the API only. Nothing is added to your workflows, so there is no monitoring node that can itself be deactivated.

Why does my n8n workflow work when I test it but not automatically?

Test runs execute an inactive workflow from the editor. Automatic runs need the workflow to be active, and for webhooks they need the Production URL, not the Test URL that only listens while the editor is open.

Why is my n8n Schedule Trigger not firing?

Most often the workflow is inactive, the cron expression means something else, or the timezone differs from what you expect. Less often the instance restarted and brought the workflow back inactive, or the Cloud plan hit its execution limit.

Why does my webhook return 404 in n8n?

Either the workflow is inactive (the Production URL is only registered while active), or you are using the Test URL outside the editor, or WEBHOOK_URL behind a reverse proxy points at the wrong host, so the path n8n registered differs from the one you copied.

Does n8n alert me when a workflow stops running?

Not by itself. The Error Workflow only runs when an execution throws; a workflow that never starts produces no execution and no error. You need something that knows when a run was due: a schedule-checking template, a heartbeat, or a monitoring service.