n8n workflow stopped running? The 7 silent-failure causes

The failure with no error message

An n8n workflow that throws an error is annoying but manageable - it lands in the executions list marked “error,” and if you’ve wired up an Error Trigger, someone gets an email. The failure that actually hurts is different: the workflow just stops. No red banner, no failed execution, no notification. It ran yesterday. Today it didn’t run at all, and nothing in n8n is shouting about it, because from n8n’s point of view nothing went wrong - the workflow simply wasn’t invoked.

This is the class of failure that erodes trust fastest, because you usually find out from the client: “hey, did the report not go out this week?”

Below are the seven most common causes of an n8n workflow going silent, each with how to detect it and how to close it off for good.

1. Expired or rotated credentials

Credentials in n8n aren’t just API keys - OAuth2 connections expire, refresh tokens get revoked when a user changes their password, and service accounts get rotated by whoever owns the upstream system. What happens when a credential dies mid-flow depends on the node. A node with “continue on fail” set will often let the execution finish and report success, even though the actual work never happened.

Detection: Check the credential’s “last verified” state periodically, not just at setup time. For OAuth2 credentials, watch for refresh failures in the execution data of nodes that use them. If executions are still marked successful but a downstream system stops receiving data, a dead credential is one of the first things to check.

Fix: Set calendar reminders ahead of known expiry windows, and avoid “continue on fail” on any node whose failure should actually stop the workflow and raise a real error.

2. Workflow accidentally deactivated

Someone opens a workflow to look at it, and the “Active” toggle gets flipped off - sometimes an accidental click, sometimes a teammate deactivating it while debugging and forgetting to switch it back on. A deactivated workflow with a schedule or webhook trigger simply never runs again. It isn’t erroring. It isn’t queued. It’s off.

Detection: Invisible from inside n8n’s own error surfaces - no execution to inspect, just nothing. The only reliable signal is the absence of expected executions over time.

Fix: Restrict who can toggle production workflows, and treat “activate” as a deploy-worthy action with a second pair of eyes when possible. For client-facing work, a periodic check of active-versus-expected-active catches this before the client does.

3. Webhook registration lost after a restart or URL change

Webhook-triggered workflows depend on n8n having registered the webhook URL, either with itself or with a third party (a CRM or scheduling tool that needs a URL configured on its end). An instance restart can, depending on version and setup, need webhooks to re-register - and if the base URL changes (a new domain, a reverse-proxy change, an instance migration), any third-party service still POSTing to the old URL gets silence back, not an n8n error, because n8n never receives the request at all.

Detection: From inside n8n there is nothing to see - the execution never starts. Check from the sending side: does the third-party service show delivery failures, or nothing at all because it’s fire-and-forget with no retry of its own?

Fix: After any instance restart, redeploy, or URL change, manually re-trigger or verify each externally-registered webhook. Keep a running list of exactly which external services point at which webhook URLs - the kind of thing nobody remembers under pressure six months later.

4. Schedule trigger lost after instance restart or timezone/DST change

Schedule and cron triggers are re-registered by n8n when a workflow activates, but they depend on the instance’s own scheduling being intact - and on a timezone assumption that’s easy to get wrong. A workflow scheduled for “9am” is 9am in whatever timezone the trigger or instance is configured for, and DST transitions can quietly shift that by an hour twice a year if the handling isn’t consistent. A restart that doesn’t cleanly reload scheduled triggers, or a deactivate/reactivate cycle where the schedule doesn’t survive the round trip, can leave a workflow that looks active but never fires again.

Detection: Compare expected run time against actual execution timestamps. A silently broken schedule shows a clean run history right up until a specific date, then nothing - often correlating with a maintenance window, an upgrade, or a DST boundary.

Fix: After any restart or upgrade, verify schedule triggers actually fired at their next expected time. Where configuration allows it, pin an explicit timezone rather than relying on system defaults, and mark DST transition dates on your calendar.

5. Upstream API rate limits returning “successes” with empty bodies

Some upstream APIs don’t return a clean 429 or 5xx when you’re rate-limited - they return a 200 with an empty array or a payload that technically parses but contains nothing useful. To n8n, that’s a successful execution: the HTTP Request node got a 2xx, nothing errored. But no data moved, so the workflow did nothing that day.

Detection: This is the classic “zombie success” - an execution that’s green but produced no meaningful output. Because it doesn’t error, it slips past an Error Trigger and past every mechanism n8n gives you that’s keyed off execution status. You need something that looks at the shape of the output, not just the status, and asks whether a workflow that normally moves N items just moved zero.

Fix: Where the API allows it, check for and explicitly handle rate-limit responses rather than trusting HTTP status alone - inspect the response body for expected fields and throw a real error (an IF node routing into a Stop and Error node) when it’s empty when it shouldn’t be. That turns a silent zombie into a loud, catchable error.

6. Queue backpressure in scaled/queue mode

In n8n instances running in queue mode (a main process handing executions to a Redis-backed queue, worked by separate worker processes), jobs can pile up faster than workers process them. If workers fall behind, are misconfigured, or one crashes, jobs can sit queued indefinitely. Depending on configuration, some triggers, particularly webhooks under sustained backpressure, may end up dropped or badly delayed rather than retried cleanly.

Detection: Queue depth and worker health aren’t things the executions list shows cleanly. This needs infrastructure-level monitoring - queue length, worker health, and whether execution timestamps drift later than trigger timestamps over time.

Fix: Monitor the queue itself (Redis metrics) alongside n8n, size worker count to actual peak load rather than average load, and alert on queue depth crossing a threshold rather than only on individual execution failures.

7. A human edit that broke the trigger path

The most common cause, in practice, is also the least technical: someone edited the workflow. A trigger node got disconnected while rewiring something else. A branch that used to run got moved behind a new IF node with a condition that’s now always false. A sub-workflow call target got repointed and the caller silently stopped invoking anything. None of these are n8n bugs - they’re config drift introduced by a well-meaning edit that didn’t get tested end-to-end before being left active.

Detection: Same signature as the others - a workflow with a healthy run history that goes quiet right after a save. If you keep any record of when workflows were last modified, cross-reference that against when executions stopped. It’s usually the same day.

Fix: Test trigger paths after any edit to a live workflow, not just the branch you meant to change. Exporting workflow JSON to version control before and after changes, even informally, gives you something to diff when a workflow that “wasn’t touched” turns out to have been touched. See config drift for how to catch edits like this before they cost you a client conversation.

Why none of these fire your Error Trigger

Look back at the list: not one of these seven causes produces an n8n execution error. A deactivated workflow doesn’t execute at all. A lost webhook registration never receives the request. A broken schedule never fires. A rate-limited API call that returns 200-with-empty-body completes “successfully.” Queue backpressure delays or drops jobs without necessarily recording a failure. A miswired trigger path just runs a different, shorter, quieter path than it used to.

The n8n Error Trigger and error workflow setting are genuinely useful, and you should have them configured (see what the Error Trigger can’t catch for the full breakdown) - but they’re built to catch exceptions during execution, and every cause above happens either before execution starts or without ever throwing one. You cannot alert on an error that doesn’t exist. Polling the executions list REST API for failed runs has the same blind spot: it only shows what n8n decided to log, and n8n never logs the absence of a run.

Detecting silence from outside

The pattern underneath all seven causes is the same: a workflow that used to run on a predictable rhythm stops running, and nothing inside n8n notices, because nothing inside n8n is designed to notice the absence of an event. Catching that means asking “did this workflow run when it was supposed to,” not “did anything error.”

That means learning each workflow’s normal cadence (daily at 6am, every 15 minutes, a few times an hour by webhook) and alerting when “now minus last successful run” exceeds that interval by some grace window - enough margin to absorb a slow run without paging anyone at 2am for nothing, but tight enough to catch a real gap quickly. It doesn’t care why the workflow went quiet, only that it did.

Building this yourself means standing up something that polls the executions API on its own schedule, stores a rolling expectation per workflow, and tracks state independently of the instance it’s watching - a check living inside the same instance that just went silent can go silent right along with it. This is the specific gap Midwatch was built to close: it watches from outside your instance, learns each workflow’s cadence from its execution history, and alerts when a workflow goes quiet past its grace window - typically catching a stall within about 10 minutes, versus the up-to-13-hours delay we saw with a daily-digest DIY setup on our own dogfood fleet before we built this. See the mechanics on how it works, or look at a sample report to see what a caught silent failure looks like once it reaches a client.

Whichever way you close the gap, the fix is the same: stop waiting for an error these seven causes will never produce, and start watching for the silence instead.