Your n8n Workflow Stopped Triggering and Nothing Told You: Catch Dead Webhooks and Polling Triggers

31 Oct 2026

Most monitoring setups for n8n answer one question: did an execution fail? That covers a lot. It doesn't cover the outage agencies get blamed for most: the workflow that simply stopped running.

A lead form that used to post to an n8n webhook gets rebuilt and now posts somewhere else. A Schedule Trigger keeps its old interval because nobody re-published the workflow. A polling trigger quietly loses access and stops picking up new rows. In every case the executions list goes quiet. Nothing is red, nothing reaches your error workflow, and the first alert is the client asking where the leads went.

This guide covers that one problem: triggers that stop firing. It explains why n8n can't tell you about it by itself, how to build an expected-run check by hand, and how LeadPulse handles it. If you haven't set up an error workflow yet, start with Give every n8n workflow an error workflow. For runs that go green while doing nothing, see Green doesn't mean it worked. This post is about the case where there is no run at all.

The symptom: silence that looks like a slow day

A dead trigger has a recognisable shape:

The workflow is still published (active) in the n8n editor.
The last execution was hours or days ago, and it succeeded.
There are no failed executions, so the error workflow never ran.
Downstream, the CRM, sheet or inbox has stopped getting new records.

The trouble is that silence is also what a quiet Sunday looks like. A workflow that handles inbound leads may legitimately see nothing for six hours. So "no executions" isn't an error by itself. It only becomes one when you compare it with what you expected to happen. That comparison is the whole trick, and n8n doesn't make it for you.

Why it happens

The error workflow only sees executions

n8n's error workflow runs "if an execution fails" (n8n docs: Handle errors gracefully). If no execution starts, nothing fails, and the Error Trigger has nothing to react to. There is one partial exception: when the trigger node itself errors (for example while the workflow is being activated), n8n sends the error workflow a payload with a trigger object instead of an execution, with an error name such as WorkflowActivationError. That's useful, but it only fires when n8n notices a problem. A webhook that nobody calls produces no problem to notice.

Webhooks: the caller stopped calling, or calls the wrong URL

The Webhook node has two URLs. Per the Webhook node common issues page, the Test URL only listens for 120 seconds after you select "Listen for test event", and its data shows in the editor. The Production URL listens from when you publish the workflow until you unpublish it. Common ways this breaks in client work:

Someone pasted the Test URL into the form tool during setup. It worked during the demo and never again.
The workflow was unpublished, for example while editing, and never re-published.
The webhook path or method changed. n8n only allows one webhook per path and method combination, so duplicating a workflow and changing the path is a common way to leave the source app pointing at a path that no longer exists.
The source app was rebuilt, its webhook subscription was deleted, or its own integration was paused. From n8n's side this is indistinguishable from "no new leads".
On n8n Cloud, a webhook that doesn't respond within 100 seconds fails with a 524 at Cloudflare. The caller sees the error. Your n8n instance may not show anything useful.

Schedule Triggers: changes that don't apply until you re-publish

The Schedule Trigger common issues page documents a few surprises:

Changing the trigger interval on a published workflow doesn't take effect until you unpublish and publish a new version.
Variables used in the trigger are only evaluated when the workflow is published.
The schedule starts from the time you publish. Changing from hourly to every two hours at 11:30 makes the next run 13:30.
Wrong time zones (instance-level GENERIC_TIMEZONE on self-hosted, or the workflow's Timezone setting) make runs happen at the wrong hour, which looks like missed runs if you check at the expected hour.

Polling triggers: the poll runs, but finds nothing

App triggers such as Google Sheets Trigger or Gmail Trigger poll on an interval. If the poll keeps running but the upstream data moved (a renamed sheet tab, a new folder, a changed label), the trigger can keep running without picking up the records you care about. If the poll starts failing outright, for example because a credential stopped working, you may get trigger errors instead. Credential failures are a big enough topic that they get their own post.

Self-hosted infrastructure

If n8n itself is down, restarting, or running queue mode with a stuck worker, nothing runs and nothing in n8n can alert you, because the thing that would send the alert is the thing that's down. Any check that lives inside the same instance shares its fate.

How to detect it by hand

There are two honest approaches. Use the first for workflows that should run on a known rhythm, and the second when you need a check that survives the n8n instance going down.

Approach 1: an expected-run check inside n8n

The idea: a separate "watchdog" workflow runs on a schedule, asks n8n when each important workflow last succeeded, and alerts if that's longer ago than you'd accept.

Build it like this:

Create an n8n API key in Settings > n8n API. The public API authenticates with the X-N8N-API-KEY header (n8n API authentication).
Create a new workflow called something like Watchdog: expected runs. Add a Schedule Trigger that runs every 30 or 60 minutes.
Add a Code node (or a Set node) that outputs one item per workflow you care about, with its workflow ID and the longest silence you'll accept, in hours.
Add an HTTP Request node that calls the executions endpoint of the n8n public API for each item, asking for the most recent successful execution of that workflow. Send your API key in the X-N8N-API-KEY header. Alternatively, use the built-in n8n node with the Execution resource and a credential using the same key.
Add a Code node that compares the newest execution's finish time with the allowed silence, and keeps only the workflows that are overdue.
Add an IF node (or route directly) to your Slack, email or Telegram node with the workflow name, the last success time and how many hours it's been.
Set this watchdog's own Error workflow in its settings, so you hear about it if the watchdog breaks.

The request for the latest success of one workflow looks like this (replace the host and ID):

GET https://n8n.example.com/api/v1/executions?workflowId=WORKFLOW_ID&status=success&limit=1
X-N8N-API-KEY: <your key>

A minimal comparison in the Code node, assuming each item carries maxSilenceHours and the API response's newest execution:

const last = $json.data?.[0]?.stoppedAt;
const limitMs = $json.maxSilenceHours * 3600 * 1000;
const overdue = !last || (Date.now() - new Date(last).getTime()) > limitMs;
return overdue ? [{ json: { ...$json, last, overdue } }] : [];

Field names in the response can differ between n8n versions, so run the HTTP Request node once and check the actual output before you trust the expression.

Three things make this check useful rather than noisy:

Pick the window per workflow. A form-intake workflow might get 6 business hours. A nightly sync gets 26 hours. A 15-minute schedule gets 45 minutes. Use the longest gap you'd be comfortable explaining to the client.
Check that the workflow is still active. The workflows endpoint exposes an active flag. A workflow that was unpublished is a different (and easier) alert than one that's published but silent.
Alert once. Store the last alert time (for example in a data table or a sheet) and only alert again when the state changes. Otherwise the watchdog becomes the noise people mute.

Approach 2: a heartbeat at the end of the success path

A heartbeat flips the logic. Instead of asking n8n what ran, the workflow itself calls a URL every time it actually delivers, and something outside n8n notices when the calls stop. This is the classic dead man's switch.

Add an HTTP Request node as the last step of the success path, after the CRM write or email send, not on the error branch. Put it where a real delivery would pass.
Point it at a heartbeat URL from whatever external checker you use.
If you know how many records the run handled, send the count. A count of zero tells you the workflow ran and delivered nothing, which is a different problem from not running.
Set the expected interval a little wider than the normal rhythm, so one slow run doesn't page you.

The advantage of a heartbeat is that it works when the n8n instance itself is down, unreachable, or out of workers, because the checker is somewhere else. It also works the same way for Make, Zapier and custom scripts. The disadvantage is that you have to add a node to every workflow you care about, and keep it on the right branch when people edit the workflow.

Quick manual checks while you're there

When a client says "nothing came through", these are the fastest checks:

In the workflow's Executions list, look at the timestamp of the last run. If it stops at a clear point in time, ask what changed then.
Open the Webhook node and compare the Production URL with what the source app is calling. Make sure the URL doesn't contain webhook-test.
Confirm the workflow is published. If you changed a Schedule Trigger interval, unpublish and publish again.
Fire the production webhook yourself with curl and see if an execution appears:

curl --request POST https://n8n.example.com/webhook/your-path --data 'test=1'

In the source app, check its delivery log for the webhook. Many form tools and CRMs show recent attempts and response codes.

How LeadPulse catches it

LeadPulse was built around this exact gap. Its rules look at outcomes rather than only errors, and the checker runs every 10 minutes.

For n8n, you connect an instance with its base URL and an API key. LeadPulse imports the workflows and reads executions. You then set outcome rules per workflow, including silence after N hours (no successful run within the window you choose) and deactivation (a workflow that used to run is no longer active). It also has rules for zero-item successes, error rate, and a drop against the trailing 7-day pace, which catches the "it still runs but writes two leads instead of forty" version of the same problem.

For workflows you can't poll, and for Make, Zapier or custom agents, LeadPulse gives you a heartbeat URL. It accepts GET or POST, optionally with ?count= or a JSON body. If the next call is later than the interval you set, the check is overdue. If the call arrives on time with a count of 0, that's a separate zero-count alert. Leaving out the count is not treated as zero.

Either way, an incident sends one alert and then stays quiet on later checks. When the workflow starts delivering again you get a recovery note. Email alerts are on every plan, including Free. Slack, Telegram and webhook alerts are on the 14-day trial and paid plans. See pricing for the limits.

Try it on your own instance

If you want to know which of your workflows have already gone quiet, run the free n8n Health Check. Paste your n8n base URL and an API key (read-only is enough), and it scores your workflows with the same rules the monitor uses, including silent workflows, triggers that haven't fired, and inactive workflows that used to run. No account is needed, the key is used for that one scan and not stored, and you enter your email to see the results. If you'd rather keep watching a few workflows continuously, the Free plan covers 1 instance and 3 monitored workflows with email alerts.