Huginn vs n8n for RSS-to-Webhook: Which Self-Hosted Watcher Still Misses Items

I did not install Huginn because I wanted a hobby. I installed it because a changelog feed posted three times in an hour, my webhook only saw the last item, and the two CVEs in the middle had already been discussed on a mailing list I do not read. n8n did the same thing a month later with a prettier canvas and a green checkmark.

RSS-to-webhook is the most boring automation in a homelab and the one that lies with the most confidence. Both tools will tell you the agent ran. Both will miss items. They miss for different reasons, and that is the actual comparison.

What you think you subscribed to

A feed is not a log. It is a window. Most publisher feeds keep ten to twenty items. Some keep one. A few Atom feeds rewrite the same entry id every time the page changes. Podcast feeds put a stable GUID on the enclosure. Random WordPress sites put a date in the title and call it a day.

Your watcher polls. If the window slides past an item between polls, that item is gone. If you were down for a Docker upgrade, the window slid without you. If the feed 429s and your agent counts that as “nothing new,” you also miss. None of this is unique to Huginn or n8n. The difference is what each tool remembers after a successful fetch, and what it does when the fetch is not successful.

I run both against the same five feeds for a month whenever I change the stack: two project Atom feeds, one CVE RSS, one blog that only shows eight items, and one status page that recycles GUIDs. The score is never 5–0.

Huginn’s memory is a bag of seen events

Huginn’s RSS Agent fetches, emits events, and keeps a memory of what it already saw. That memory is the product. When it works, you get one event per new item and a webhook Agent downstream that POSTs JSON to ntfy, Discord, or a tiny script. When it fails, it is usually one of three things.

First, max_events and the feed length. If the agent only keeps a short memory and the feed dumps fifteen items after a release day, Huginn can emit a burst — or, if you configured it to be timid, it can treat the burst as noise. I have had an agent that “caught up” by emitting the newest item and forgetting the rest of the window. That is not a crash. The UI looks healthy.

Second, identity. Huginn has to decide what “same item” means. URL, GUID, title. A feed that changes the GUID on every rebuild looks like an infinite stream of new posts. A feed that keeps the GUID and rewrites the title looks like silence. I spent a week thinking a vendor had stopped shipping notes. They had shipped four. The GUID never changed. Huginn was correct and useless.

Third, process death. Memory lives in the database if you set the stack up like an adult. If you run Huginn the way a lot of Compose files still do — a volume you forgot, a SQLite file inside a container you recreate — the agent wakes up empty and either replays the whole window or treats everything as already seen, depending on how you left expected_update_period_in_days and friends. I have done both. The replay path is embarrassing. The silent path is worse.

n8n’s RSS nodes are a schedule wearing a trigger costume

n8n gives you an RSS Feed Trigger and an RSS Read node. The trigger feels event-driven in the editor. On your box it is still a poll. The interval you pick is the miss budget. Five minutes is fine for a blog. Five minutes is how you lose two items on a busy CVE feed that only keeps ten entries if you also hit a slow DNS blip.

n8n’s advantage is operational, not magical. Failed executions are visible. You can retry. You can pin data. You can add an error workflow that pages you when the fetch throws. Huginn will log; n8n will put a red box on a canvas you already have open because something else failed. I notice n8n misses sooner. I do not miss fewer items because of the canvas.

The Read node on a cron is honest. You fetch, you compare to static data or a Data Table or a Postgres row you maintain yourself. That last part is the trap. People assume the Trigger remembers forever. It remembers in n8n’s execution and static-data world. Restart the container, change the workflow, toggle it off and on, and you can reset that memory. Then you get a webhook storm or a quiet skip. Same two failure modes as Huginn, nicer icons.

Credentials and HTTP details are where n8n wins for ugly feeds. Cookie, user agent, basic auth, a header the origin wants. Huginn can do it. You will do it in a Liquid-ish option hash and feel like you are editing a 2014 Rails app, because you are. If half your “RSS” is a Cloudflare-gated URL, I start in n8n.

The miss that is not the tool

Both miss when you poll a feed that is not the source of truth. GitHub release feeds are usually fine. Project “news” pages generated by a static site that only rebuilds the latest post are not. Status pages that put “All systems operational” in one item forever are not feeds. Scraping the HTML and calling it RSS is how you get empty descriptions and duplicate links.

I keep a rule: if the feed does not have a stable GUID or a stable per-item URL, I do not use RSS-to-webhook. I use an HTTP poll against the releases API, or I accept that I will miss. Huginn’s Website Agent and n8n’s HTTP Request node are the grown-up versions of this workflow. The RSS agents are for feeds that behave.

Retry, backoff, and the green dashboard

Huginn will retry on a schedule you defined when you created the agent. If the remote is down for the whole window of a short feed, retries do not reconstruct vanished items. n8n retries the execution. Same limit. The item is not on the server anymore. Your watcher cannot fetch the past from a window.

This is why I pair either tool with a second, slower catch-up. Once a day, a workflow fetches the same feed with a larger “seen” store — a SQLite table of GUIDs I own — and POSTs anything missing from the last 48 hours. Huginn can do that with a second agent. n8n can do that with a scheduled workflow and a database node. The daily job is ugly. It is also the only reason I still trust webhooks for security notes.

Uptime Kuma on the Huginn or n8n URL will tell you the process is up. It will not tell you the last CVE made it to Discord. Healthchecks.io on a “I emitted at least one catch-up ping” is closer. I ping a heartbeat from the daily GUID job, not from the pretty trigger.

When Huginn is the better watcher

Huginn is better when the path is a graph of small agents: RSS to Trigger to Weather to Post, or RSS to a Deduplication Agent you understand. It is better when you want the thing running for years with almost no UI. It is better when you already have it and the alternative is “migrate thirty agents to n8n because a canvas is modern.”

It is worse when you need other people to debug it. The event log is a list. The options JSON is a personality test. If you will not look at it for six months, leave a comment in the agent description that says what GUID means for that feed. Future you is a stranger.

When n8n is the better watcher

n8n is better when RSS is one node in a workflow that already talks to IMAP, a REST API, and a Docker socket. It is better when you want error workflows and a credential store. It is better when you will add a human approval or a filter that is easier to see than to remember in Huginn Liquid.

It is worse when you treat the Trigger as a message queue. It is a poller. If you need “never miss,” you need storage you control and a catch-up. n8n makes that easy to build and easy to forget.

A setup that misses less

I run n8n for new RSS-to-webhook paths and leave Huginn on the agents I have not broken. For any feed I care about:

• Poll at an interval shorter than the feed’s likely burst, knowing that still fails if the window is tiny.
• Key identity on GUID, then URL, never title alone.
• Write every seen GUID to Postgres or SQLite, not only to the tool’s implicit memory.
• Run a daily catch-up that walks the current window against that table.
• Heartbeat the catch-up, not the poll.
• Keep a raw copy of the last successful XML in object storage for a week so I can prove what the origin sent.

That last bullet has settled arguments. The origin sent two items. The tool emitted one. The XML is the referee.

The honest score

Huginn misses when memory and identity disagree with the feed. n8n misses when the poll interval and implicit static data disagree with the feed. Both miss when the feed is a window and you were not looking. If your webhook is a nice-to-know blog, pick the UI you will actually open. If your webhook is “a CVE existed,” neither default agent is enough. Build the GUID table. Accept that RSS was never a queue.

I still use both. I just stopped believing the green check.