5 Ways n8n Workflows Die That Your Error Trigger Never Catches

If an n8n workflow is not running and nothing alerted you, it has almost always hit one of five silent failures: an expired token on the trigger, a schedule in the wrong timezone, a webhook the sender stopped waiting for, a change in the incoming data, or a plan limit that left the run in a queue. None of these produces a failed execution, and a failed production execution is the only thing an error workflow reacts to, so your Error Trigger stays quiet through all five.

Checked October 2026 against n8n's docs on executions, publishing, the Schedule Trigger, the Webhook node, Cloud concurrency and the durable scheduler, n8n's pricing page, and the source of n8n 2.42.6, the stable release on 9 October 2026. Sender timeouts come from the Shopify, GitHub and Stripe webhook docs.

This checklist is part of our n8n hub. It starts where the Error Trigger guide and the wider n8n error handling guide stop: those cover the failures n8n records, and this page covers the ones it does not. It is built from n8n's documentation and source code, not from a test bench. The probe workflows were checked against the node source for 2.42.6 and not executed, so run each one once by hand before you rely on it.

Why is my n8n workflow not running? Read the Executions tab first

The Executions tab tells you which kind of failure you have. An error workflow runs only when a production execution fails, so the first three states below never reach it.

1. Expired tokens: the trigger that stops hearing events

A token that expires in the middle of a workflow is loud: the node returns 401, the execution fails and your handler runs. The silent version is a token that expires on the trigger, and what happens next depends on how that trigger gets its data.

• Polling triggers such as the Google Sheets Trigger ask the provider on a timer. When a poll fails, n8n records an error execution and calls the error workflow, but with a trigger object instead of execution (source). A handler that reads only execution.error.message breaks on it.
• Webhook-style app triggers register a subscription with the provider when you publish. After that n8n makes no calls of its own, so nothing can fail. If the provider stops delivering because access was revoked or the subscription lapsed, n8n records no execution at all.
• After a restart n8n activates every published trigger again. A failed activation is retried with a delay that doubles from one second up to one day. The exception: when the error message contains "Authorization", n8n calls the error workflow once and does not retry (active-workflow-manager.ts).

The most common cause is documented by n8n itself. For a Google Cloud app with publishing status Testing and user type External, its Google OAuth page says "consent and tokens expire after seven days". Publish the OAuth app, or plan for a weekly reconnect.

Probe: a canary workflow. Add a Schedule Trigger that runs once a day, then one cheap read per critical credential, such as fetching a single row. Leave each node's On Error on Stop Workflow. A dead token now fails inside an execution, on your schedule, where the Error Trigger does work. Select your handler under Settings, Error Workflow, and make sure it reads both payload shapes.

2. Timezone drift: the schedule that runs at the wrong hour

A schedule in the wrong timezone does not fail. It runs, on time, at an hour nobody wanted. The Schedule Trigger docs give the order: the workflow's Timezone setting first, then the instance timezone. Self-hosted n8n defaults to America/New_York until you set GENERIC_TIMEZONE. n8n Cloud tries to detect the owner's timezone at sign-up and falls back to GMT.

• Edits wait for a publish. A changed interval only takes effect after you publish again, and an interval schedule then counts from the moment you published.
• Variables are read once. A variable inside a cron expression is evaluated when the workflow is published, not on every run.
• Downtime eats runs. With the default in-memory scheduler, n8n "skips any run whose time passed during the downtime rather than catching it up". The durable scheduler, available from n8n 2.36.0 and off by default, records runs in the database and lets a Schedule Trigger run the most recent missed execution.

Probe: the Schedule Trigger already tells you where it thinks it is. Its output carries a Timezone field such as Europe/Berlin (UTC+02:00) (source). Put an If node after it with this condition, and wire the false branch to a Stop and Error node:

{{ $json.Timezone.startsWith('Europe/Berlin') }}

For the schedule itself, our n8n cron expression guide has the common patterns and the free cron generator builds the expression for you.

3. Webhook timeouts: n8n succeeds, the sender gives up

Here both sides are honest and they disagree. n8n runs the workflow to the end and marks it successful. The sender stopped waiting long before, logged a failed delivery and scheduled a retry.

The fix is to answer first and work second. Set the Webhook node's Respond option to Immediately, or place a Respond to Webhook node straight after validation, then de-duplicate on the sender's event ID because retries will arrive. Our n8n webhook guide walks through both. Three more quiet exits sit on the same node:

• Only Run If. A request that does not match the option's expression gets a 200 response "without creating an execution", so a renamed field can switch a workflow off.
• Ignore Bots. Requests from link previewers and crawlers are dropped.
• The test URL. It only listens for 120 seconds after you select Listen for test event. A sender pointed at it works once and never again.

Probe: a scheduled HTTP Request node that posts a marked payload, for example { "canary": true }, to your own production URL, with the node's Timeout option set to your strictest sender's limit (5000 ms for Shopify). If n8n answers too slowly, the request errors and the canary execution fails. Have the real workflow drop canary payloads after it has responded.

4. Data-shape changes: green executions that did nothing

An upstream app renames a field, wraps its response in a new object or starts returning an empty list. Nothing throws. The execution is green and the row was never written. Four behaviours keep it quiet:

• Empty output ends the branch. A node that returns no items passes nothing on, and the run still counts as a success. The node setting Always Output Data exists for this: with it, the node "returns an empty item even if the node returns no data".
• If drops what you did not wire. A comment in n8n's If node source puts it plainly: the node "silently drops items routed to an unwired branch".
• Quiet polls leave no trace. A polling trigger that finds nothing new starts no execution, so "no new rows" and "the filter no longer matches anything" look identical.
• Continue hides the error. A node whose On Error is set to Continue keeps the run alive, so the execution never counts as failed.

Probe: a contract check straight after the trigger. Add an If node whose condition lists the fields the rest of the workflow reads, and wire the false branch to Stop and Error. The field names below are examples:

{{ ['email', 'order_id', 'total'].every(key => $json.body[key] !== undefined && $json.body[key] !== '') }}

On lookups that may return nothing, turn on Always Output Data and test the next step with {{ $json.isEmpty() }}. A missing record then becomes a branch you chose, not a run that ended early.

5. Plan limits: why an n8n execution gets stuck in the queue

Limits delay or stop runs without failing them. Three are documented:

• Concurrency. n8n Cloud caps concurrent production executions by plan: 5 on Starter and on the trial, up to 50 on Pro (pricing page, checked October 2026). Runs over the cap "queue for later processing" in first-in, first-out order, and a queued execution cannot be retried. Self-hosted n8n has no cap until you set N8N_CONCURRENCY_PRODUCTION_LIMIT, then behaves the same way.
• Timeouts. Cloud enforces a maximum workflow timeout for each plan, and the trial's is 180 seconds. Self-hosted instances have none unless EXECUTIONS_TIMEOUT is set.
• The trial itself. It includes 1,000 executions, and if you do not upgrade when it ends, "n8n deletes your workspace".

What about the monthly execution quota? The pricing page answers that only for Business and Enterprise: workflows "continue running without interruption" and overage charges may apply. For Starter and Pro it does not say what happens at the quota, so watch your production execution count under Insights. Our n8n pricing guide covers what counts as an execution, and the self-hosted limitations guide covers the concurrency setting.

Probe: a heartbeat. A probe inside n8n cannot see this failure, because it is a production execution too and waits in the same queue. Use a workflow on a five-minute schedule that calls a heartbeat URL at a monitor outside n8n, which alerts when the pings stop. Add an outside check on /healthz, which n8n's monitoring docs say returns 200 when the instance is reachable, on self-hosted and Cloud alike.

The five probes side by side

The catch-all probe: a watchdog that alerts on silence

Failures 1 to 4 share one symptom: a workflow that should have succeeded recently has not. One watchdog covers them all. It asks the n8n API for the watched workflow's most recent successful execution and fails on purpose when that is too old, which sends the alert through the error workflow you already have.

{
  "name": "Silence watchdog",
  "nodes": [
    {
      "parameters": {
        "rule": {
          "interval": [
            {
              "field": "hours",
              "hoursInterval": 1
            }
          ]
        }
      },
      "id": "d4b9f5c2-0001-4f3e-8b4d-000000000001",
      "name": "Every hour",
      "type": "n8n-nodes-base.scheduleTrigger",
      "typeVersion": 1.2,
      "position": [
        0,
        0
      ]
    },
    {
      "parameters": {
        "resource": "execution",
        "operation": "getAll",
        "limit": 1,
        "filters": {
          "workflowId": {
            "__rl": true,
            "mode": "id",
            "value": "REPLACE_WITH_WORKFLOW_ID"
          },
          "status": "success"
        },
        "options": {}
      },
      "id": "d4b9f5c2-0002-4f3e-8b4d-000000000002",
      "name": "Last successful run",
      "type": "n8n-nodes-base.n8n",
      "typeVersion": 1,
      "position": [
        220,
        0
      ],
      "alwaysOutputData": true
    },
    {
      "parameters": {
        "conditions": {
          "options": {
            "caseSensitive": true,
            "leftValue": "",
            "typeValidation": "strict",
            "version": 2
          },
          "conditions": [
            {
              "id": "d4b9f5c2-0005-4f3e-8b4d-000000000005",
              "leftValue": "={{ !$json.startedAt || DateTime.fromISO($json.startedAt) < $now.minus({ hours: 26 }) }}",
              "rightValue": "",
              "operator": {
                "type": "boolean",
                "operation": "true",
                "singleValue": true
              }
            }
          ],
          "combinator": "and"
        },
        "options": {}
      },
      "id": "d4b9f5c2-0003-4f3e-8b4d-000000000003",
      "name": "Too quiet?",
      "type": "n8n-nodes-base.if",
      "typeVersion": 2.2,
      "position": [
        440,
        0
      ]
    },
    {
      "parameters": {
        "errorMessage": "=Watched workflow has no successful run in the last 26 hours. Last success: {{ $json.startedAt || 'none found' }}"
      },
      "id": "d4b9f5c2-0004-4f3e-8b4d-000000000004",
      "name": "Raise the alarm",
      "type": "n8n-nodes-base.stopAndError",
      "typeVersion": 1,
      "position": [
        660,
        -80
      ]
    }
  ],
  "connections": {
    "Every hour": {
      "main": [
        [
          {
            "node": "Last successful run",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Last successful run": {
      "main": [
        [
          {
            "node": "Too quiet?",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Too quiet?": {
      "main": [
        [
          {
            "node": "Raise the alarm",
            "type": "main",
            "index": 0
          }
        ],
        []
      ]
    }
  },
  "settings": {
    "executionOrder": "v1"
  }
}

Two design notes. The API returns executions newest first, so a limit of one is enough. And the n8n node has Always Output Data switched on, so a workflow with no successful run at all still reaches the If node and trips the alarm. The watchdog reads only status and timestamps, never your data. It fits anything that should run on a rhythm. For a webhook with irregular traffic, pair it with the canary from failure 3 so there is always one known event to count.

n8n workflow stopped working after an edit or a restart?

Then check publishing before anything else. These are the items people skip because the canvas looks right.

If these workflows are turning into something customers depend on, the same habits carry over to application code. Our AI SaaS Builder program has no n8n lessons, but it does cover production hardening for Claude API features (errors, rate limits and fallbacks) and analytics for a deployed app.

n8n workflow not running: FAQ