How do you catch a polling trigger that just stops?

Built with n8n
1

Quick question for people running error workflows in production: how do you catch a polling trigger that just stops?

In a lab test I ran on n8n 2.41.3, a broken RSS trigger produced no execution and no alert in 12 minutes, so the Error Trigger had nothing to respond to. A published error workflow in the same test caught 25 of 25 scheduled failures, but it never fired for silent triggers like this one. I ended up adding an outside heartbeat for missing runs.

What do you use for that — an external monitor, a scheduled check workflow, or something else?

Full tested setup, with the four blind spots and fixes:

إعجابَين (2)
2

Hi @operantsolo, a healthy RSS Trigger also produces no execution when the feed has nothing new, so a heartbeat on missing runs can’t tell a quiet feed from a dead trigger. It either alerts on quiet days or needs a grace period longer than the feed’s longest gap.

Splitting it in two covers both. A second workflow on a Schedule Trigger fetches the feed with an HTTP Request node every hour and compares the newest item’s date with the last one the main workflow saved to a Data Table. If the feed has moved on and the main workflow hasn’t, the trigger is dead, and the check workflow sends the alert. That check workflow also pings an outside heartbeat on every run, so n8n being down shows up as a missed ping.

I use Vivere for that ping (it’s mine), but any external heartbeat with a grace period works.

3

Thanks, that’s a really useful distinction — a quiet feed and a dead trigger look identical if you only watch for missing runs.

The grace period point is the key one for me: it has to be longer than the feed’s longest gap, otherwise you just get alerts on quiet days. And splitting the check, like you describe — a scheduled workflow that fetches the feed itself and compares the newest item with what the main workflow last saved — is a much better dead-trigger test than a simple heartbeat alone, because it checks whether the feed actually moved.

The outside heartbeat on the check workflow itself is a nice second layer too, for the case where n8n itself is down.

Out of curiosity, how do you usually set that grace period in practice — do you base it on the feed’s history, or just pick a safe multiple of the normal gap?