DEV Community

Cover image for n8n 3.0 will silently kill your workflows — the 37 nodes to replace before December
Alfaz Mahmud Rizve
Alfaz Mahmud Rizve

Posted on Originally published at whoisalfaz.me

n8n 3.0 will silently kill your workflows — the 37 nodes to replace before December

n8n 3.0 stable is due in early December 2026, with the beta live since 27 October. The release removes 37 deprecated nodes, ends npm and npx installs, and shortens the Code node timeout from 300 seconds to 60.

That is all public. Here is the part that is catching people out: after the upgrade, workflows that use a removed node still show as Published in the dashboard. They just never run. No error, no failed execution, nothing in the logs.

The silent failure trap

In n8n 2.x, a workflow's active flag and its trigger nodes are separate things. In 3.0, the engine boots, scans for active workflows, and tries to start their triggers. For a workflow built on a removed node, the node package no longer exists, so the trigger never starts — but the database row still says active.

Four failure shapes, all silent:

  1. Trigger dropout. Cron and Interval triggers drop to zero active listeners. Schedules never fire. No errors logged.
  2. Execution black hole. A workflow with a Function or Function Item node shows one active trigger, but the worker aborts before the first run. Zero runs in history.
  3. Sub-workflow severance. A parent workflow runs fine, then calls a sub-workflow that contains a removed node. The child fails quietly.
  4. Saved draft poisoning. A draft containing removed nodes cannot be published on 3.0 at all. Your changes get trapped in an unpublished state.

The 37 nodes, and what replaces them

The big ones first:

  • Function → Code node ("Run Once for All Items"). Replace items[i].json with $input.all(), and return an array of objects wrapped in json.
  • Function Item → Code node ("Run Once for Each Item"). Replace item.json with $input.item.json.
  • Cron → Schedule Trigger. Move the cron expression into the Schedule Trigger. It respects GENERIC_TIMEZONE or the per-workflow timezone.
  • Interval → Schedule Trigger. Set the interval there instead.
  • Item Lists → Split Out, Aggregate, Sort, Limit, Remove Duplicates, or Summarize. One node becomes several single-purpose ones.
  • HTML Extract → HTML node (Extract HTML Content operation).
  • Read PDF → Extract from File (Extract From PDF operation).
  • Legacy OpenAI node → the current OpenAI node. Old endpoints are retired.
  • AI Agent v1 → Tools Agent. Old agent modes (Conversational, ReAct, Plan and Execute, SQL Agent) are retired. An AI Agent node on version 1.5 or lower will crash at runtime.

The other 23 are mostly LangChain-era loaders, vector store insert/load pairs (Pinecone, Supabase, Zep, in-memory), old memory providers, and chat helpers. Full matrix with every node and its replacement is in the SOP linked below.

Three more breaking changes worth knowing:

  • npm and npx installs are gone. Self-hosted n8n runs on Docker only from 3.0. Kubernetes and Helm setups are not affected.
  • $getPairedItem is removed. It throws a fatal syntax error. Use $('Node Name').item.json.property instead.
  • The upgrade is one-way. You cannot roll back from 3.0 to 2.x except by restoring a full backup. And 1.x support ends 31 December 2026 — there is no direct 1.x to 3.x path.

Why your error handler will not save you

I run a global error-handling workflow — a Watchtower built on n8n's Error Trigger — that catches crashes across my whole instance and pings me with a deep link to the failed run. It is good at its job.

It will not catch this. The Watchtower only fires when an execution starts and fails. In a trigger dropout, no execution ever starts, so the Error Trigger never fires. Nothing crashes, so nothing alerts. The first sign of trouble is a customer asking where their invoice went.

That is the real risk of 3.0: not the breakage, but the silence.

The check to run before December

Three steps, from the SOP:

  1. Scan before you upgrade. Run a static scan of your workflows for the 37 removed nodes and refactor them first. Function nodes are the most common hit.
  2. Audit the multi-output nodes. The "Always Output Data" behaviour changed for If, Filter, and Compare Datasets. Check them with the 4-input Merge pattern.
  3. Record a baseline, then watch for 48 hours. Note the median gap between runs for each active workflow before the upgrade. After the upgrade, compare. A workflow whose gap suddenly goes infinite is a silent dropout — and the dashboard will still call it Published.

The full SOP — the 37-node matrix, the runbook for Docker-hosted upgrades, and the rollback plan — is here: https://whoisalfaz.me/blog/how-to-upgrade-to-n8n-3-without-breaking-workflows/

The Watchtower error-handling build is here: https://whoisalfaz.me/blog/n8n-global-error-handling/

If you run n8n for clients, I also wrote up the automation service behind this work: https://whoisalfaz.me/services/n8n-automation/

And if you want a second pair of eyes on your own setup, the audit tool I built is free: https://whoisalfaz.me/audit/

Check your workflows before December. The ones that look fine are exactly the ones to worry about.


Alfaz Mahmud Rizve — GTM & RevOps Architect. I build autonomous revenue systems for scaling agencies and SaaS: SEO & organic growth, high-speed Next.js apps, and self-healing n8n workflows. whoisalfaz.me

Top comments (0)