The problem
Your workflow looks active. It shows no failed execution, no error, and no warning — it simply never runs again. That is the failure an error workflow cannot catch, because there is no execution for it to trigger on.
A polling trigger that stops polling is the quietest way an n8n workflow can fail. Nothing crashes, nothing turns red, and the execution list just ends. Days can pass before anyone notices, because every alert you have is waiting for an execution that never arrives.
Polling vs webhook
A webhook trigger waits for the sender to push an event to it. A polling trigger asks the source on a schedule — “anything new?” — and only creates an execution when it finds something. If the polling trigger itself breaks, nothing arrives, nothing fails, and n8n records nothing to alert on. That silence is the whole problem.
What is already tested
This is not a new test for this guide. In the site’s own error-workflow lab on n8n 2.41.3, a broken polling trigger produced no execution and no alert in 12 minutes. The error-workflow guide documents the method and the other failure cases — this guide builds on it instead of repeating it.
Check these first (before building a monitor)
Before you build any monitoring, rule out the ordinary explanations:
- Is the workflow still active, or was it deactivated?
- Did the credentials change, expire, or get revoked?
- Did the source URL, feed, or filter change?
- Did the polling interval change, or is the trigger waiting longer than you expect?
If any of these explains the silence, fix that first.
Proposed pattern 1: heartbeat on missing runs (NOT lab-tested — proposed)
The simplest monitor does not watch executions — it watches for their absence. A scheduled check workflow records the “last successful run” of each critical workflow, then alerts when a workflow has not run within its expected window. The proposed starting point is 3× the expected interval — for example, a workflow expected hourly would alert after about 3 hours of silence. That multiplier is a proposed starting point, not a tested value, and it must be tuned per workflow: a quiet source that legitimately has no new items will look exactly like a dead trigger to a simple heartbeat.
Proposed pattern 2, from the community discussion (NOT lab-tested — community suggestion, not an operantsolo result)
This pattern comes from a community discussion — it is a community suggestion, not an operantsolo result, and it has not been lab-tested. A heartbeat alone cannot tell a quiet feed from a dead trigger. Split the check: a scheduled workflow fetches the source feed itself and compares its newest item with what the main workflow last saved. If the feed has moved but the main workflow has not, the trigger — not the feed — is the suspect. Plus an outside heartbeat on the check workflow itself, so that n8n being down also shows up, instead of the checker silently failing along with everything else. The discussion left one question unanswered: how long a grace period to allow before calling it a failure. This guide will not invent a value for it.
Honest limits
- An error workflow cannot catch a missing run: no execution, no trigger, no alert.
- A simple heartbeat cannot distinguish “nothing new” from “trigger dead”.
- Sequential lab behaviour does not prove concurrent safety or exactly-once delivery.
- Keep this guide away from real orders and payments.
Quick checklist
- Workflow active?
- Credentials valid?
- Source URL unchanged?
- Interval as expected?
- Last successful run recorded somewhere outside the workflow itself?
- Alert on silence, not just on errors — with a grace window tuned to how often the source actually changes?
- Checker itself monitored from outside n8n?