DEV Community: Lantern Flows

Why your n8n RSS Feed Trigger is not working (checklist)

Lantern Flows — Mon, 02 Nov 2026 01:43:40 +0000

You scheduled an RSS → digest workflow. The canvas looks fine. Then… nothing. No new execution. Or the run completes with zero items. Searches for n8n rss feed trigger not working often land on docs and forum threads, so here is one checklist you can finish in about fifteen minutes.

Scope of this article: documented against self-hosted n8n 2.44.6. Not tested on n8n Cloud. When this article mentions alerts or digests, delivery examples use SMTP or Slack—not Telegram/Discord.

What “RSS Trigger” usually means in practice

In many setups people mean either:

RSS Feed Read (or similar read node) on a Schedule / Cron, or
An RSS / feed Trigger node that polls on its own interval.

Both fail for similar reasons: bad URL, inactive workflow, empty window, or “success with zero items.” Treat “not working” as no useful items reached the next node, not only a red error banner.

Checklist: why the feed path is silent

Work top to bottom.

1. The workflow is not published / active

Schedule and poll triggers only run in production on a published (activated) workflow. A manual Execute workflow click in the editor does not prove the schedule will fire overnight.

Fix: publish the workflow. Confirm it shows as active. Wait for the next poll window, then check Executions—not only the editor toast.

2. You are testing with a feed URL that does not return items

Broken HTTPS, 403 from the publisher, HTML login pages, Atom vs RSS mismatch, or a URL that used to work and now redirects can all look like “trigger not working.”

Fix: open the feed URL in a browser or curl. You should see XML (or a known feed format), not an empty 200 HTML page. Temporarily put a well-known public feed in Config, publish, and re-test. Put your real feeds back only after the path works.

3. Polling / schedule interval vs your expectations

If the schedule is “every day at 08:00” and you tested at 08:05 in the editor, you did not exercise the schedule. If a trigger polls every N minutes, the first production wait can be a full interval.

Fix: use a Manual Trigger “Run now” path (if your workflow has one) for import checks; keep the schedule for production. Align timezone on the n8n instance with the schedule you wrote.

4. Filters discarded everything (looks like “not working”)

Common silent filters:

Last N hours only (e.g. last 24h) when the feed’s pubDate is older or missing
Remove duplicates / already sent on a second run (correct behaviour: nothing new → no email)
Limit / cap after an empty upstream
Continue-on-error on Read RSS: one bad feed is skipped; if all feeds fail, you get zero items and no digest

Fix: on a test run, inspect each node’s output item count. Temporarily widen the lookback or clear the duplicate store for a controlled re-test. Do not treat “second run sent nothing” as a broken trigger if the first run already consumed those links.

5. Credentials and downstream SMTP (false “trigger” reports)

The feed may have fired, but Send Email (SMTP) failed on bad host/port/app password. From the inbox’s point of view the digest “never worked.”

Fix: open the failed execution. If RSS nodes produced items and SMTP is red, fix SMTP—not the feed URL. Prefer app passwords where the provider requires them.

6. Instance / network (self-hosted)

Outbound HTTPS from the n8n host must reach the feed origin. Corporate DNS, missing CA bundle, or IPv6-only oddities show up as read errors in Executions.

Fix: from the same host/container that runs n8n, fetch the feed URL. Fix proxy/CA settings if the host cannot reach the public internet the way your laptop can.

Minimal documented pattern (RSS → daily digest email)

A practical shape many people want:

Schedule (e.g. daily) + optional Manual Trigger for tests.
Config (Set): feed URL list, toEmail / fromEmail, lookback hours, max articles.
Split feeds → RSS Feed Read (continue on error per feed if you want bad sources skipped).
Time window filter → dedupe → limit → slim fields → aggregate.
Optional LLM “write digest” (continue on error if email must still send a fallback).
Send Email (SMTP).
Publish. Verify with Run now, then let the schedule run once in production.

Documented on self-hosted n8n 2.44.6; not tested on n8n Cloud. Import-checked patterns with sample data still need your own feed and SMTP verification.

This post was generated with an AI agent and reviewed by me before publishing.

Why your n8n Error Workflow is not triggering (and how to fix it)

Lantern Flows — Sun, 01 Nov 2026 04:25:19 +0000

Your n8n workflows can fail at 2 a.m. and tell you nothing. You add an Error Workflow, wait for the next failure… and the alert never fires.

This is one of the most common “it should work” traps in n8n. Search results for n8n error workflow not triggering are mostly docs and forum threads, so here is a single checklist you can walk through in about ten minutes.

Scope of this article: documented against self-hosted n8n 2.44.6. Not tested on n8n Cloud. Notification examples use Slack or SMTP only.

What an Error Workflow actually is

An Error Workflow is a normal workflow whose first node is an Error Trigger. You point other workflows at it under Settings → Error workflow. When a monitored workflow fails in the way n8n considers “unhandled,” the Error Trigger runs and you can send Slack or email.

It is not a global catch-all for every red node you see while clicking around in the editor.

Checklist: why it is “not triggering”

Work top to bottom. Most “not triggering” reports are one of these.

1. You tested with a manual run in the editor

Error Workflows are meant for automatic / production executions (schedules, webhooks, app triggers on a published workflow). A manual Execute workflow click in the canvas often will not invoke the Error Workflow.

Fix: publish (activate) a throwaway workflow, give it a real trigger (or Schedule), force a failure there, then check Executions on the Error Workflow—not only the editor toast.

2. The Error Workflow is not selected on the failing workflow

Open the workflow that failed → Settings (or Options → Settings) → Error workflow → pick your handler → save / publish again.

In newer n8n versions, both the monitored workflow and the error handler may need to be published. If you only saved a draft, production failures will not see the setting.

3. The failure was “handled,” so n8n does not escalate

If a node uses Continue On Fail, or you wired the node’s error output and handled it yourself, the execution can finish without counting as an unhandled workflow failure. The Error Trigger stays quiet.

Fix: for the path you want alerts on, turn off Continue On Fail and do not swallow the error on a side branch—or accept that handled errors will not page you.

4. The Error Trigger is not the first node (or the handler itself errors)

The handler must start with Error Trigger. Keep the alert path short: Error Trigger → Set/Compose → Slack or Send Email (SMTP). Avoid putting fragile HTTP/LLM steps on the critical path unless they are set to continue on error and are clearly optional.

5. You are looking at the wrong place for proof

Production Error Workflow runs show up under Executions for that workflow. They may not paint a big banner on the workflow that failed. Confirm:

the failing workflow has a failed production execution;
the Error Workflow has a matching new execution at about the same time;
Slack/SMTP credentials on the handler are valid (a bad credential makes it look like “nothing happened”).

6. Instance / URL gotchas (self-hosted)

If your alert includes an execution link, the instance public URL must be configured correctly, or the link is useless even when the trigger did fire. That is a separate issue from “not triggering,” but it is often reported together.

Minimal documented pattern (Slack or SMTP)

New workflow → Error Trigger.
Edit Fields (Set) for subject/channel/recipient prefixes.
Slack Send message or Send Email (SMTP) with workflow name, failed node, error message, and execution URL from the Error Trigger payload.
Publish the handler.
On every workflow you care about: Settings → Error workflow → select it → publish.

To force a failure on purpose: add a Stop And Error node on a published schedule/webhook workflow, run it once in production mode, then verify the handler execution.

Optional AI “explain this error” steps are fine only if they cannot block the alert (continue on error, off by default).

Documented on self-hosted n8n 2.44.6; not tested on n8n Cloud. Import-checked with sample data; real Gmail/Slack/SMTP/LLM behaviour in your environment still needs your own verification.

This post was generated with an AI agent and reviewed by me before publishing.