Unrecognized node type: n8n-nodes-base.start

Questions
1

Describe the problem/error/question

Around 08-Jan-2026, my n8n webhook stopped accepting submissions. No history or information inside n8n, just hard rejections at the interface.

What is the error message (if any)?

The caller is receiving error 500: ‘{“code” => 0, “message” => “Unrecognized node type: n8n-nodes-base.start”}’

The automation being blocked did have a start node by that name, which I deleted. This did not resolve the issue on further tests.

Examining the startup logs, I can see dozens of these types of errors;

app-n8n-1  | Activation of workflow "NAVI | Book Tour | v2" (68w9Rtxp2AXoerQp) did fail with error: "Unrecognized node type: n8n-nodes-base.start" | retry in 64 seconds

Fortunately, the webhook caller ( Basin in this case ) also keeps logs.

I regressed n8n to 2.2.5, right about when I began seeing the failure appear in the caller’s logs, the problem continued.

I further regressed to version: 2.1.4, I believe the last release in 2025, and I am no longer seeing the webhook rejections.

It appears the problem was introduced sometime between 2.1.4 and 2.2.5.

What’s causing this?

Weirdly, this was the original flow-

image
image2127×1379 241 KB

You can see the Start node in the corner, unused since this is never manually triggered.

After deleting that node from that workflow ( it still existed in others ), the problem continued.

One possibility in my mind is that the node has been deprecated, or that in a “disconnected” state it’s causing a failure. And that furthermore the problem is occurring at server startup and preventing the webhooks from initializing properly. It appears that if the node exists in any workflow, it will cause all of them to hard fail with no logging.

I’ve removed the start node from all workflows, to be safe, however I’m cautious about re-upgrading n8n it to the current build, since this is a production system.

Hoping I can get some clarity on this and how to approach it. Thanks a ton!

2

You’re right about the deprecation of the node:

All start nodes should have been removed before upgrading to v2 to be safe.
I would recommend to remove the nodes (not only disconnect it) from all workflows in your currently working n8n version and then try to upgrade again.

But the recommended upgrade path was to remove them before upgrading to any v2 version as mentioned in the migration report.

3

Thanks salman :thinking: the setup I’ve always run through Elestio is to set the n8n version to “latest”, I suppose I never anticipated the possibility of breaking changes on the workflows themselves.

Given the mad shipping pace, can you recommend a way to review breaking changes from a specific version number, so that I can check and perform any critical updates before I manually update? I could schedule a way to manually review and update my n8n install 2 - 3 times a year, but I need to figure out how to find breaking changes between vX and vcurrent

4

Hi @memetican,

Currently there are only breaking changes between version 1.x and 2. As pert the guide @salmansolutions shared you can check what needs to be updated/changed. You can also have a look at the migration tool report on which workflows you need to give attention to:

5

Thanks a ton guys, This is clearly an issue of doing my own sysops, without any bandwidth to do sysops.

A few years ago n8n stopped working because I had it fixed to a version ( due to a different upgrade issue ) and then after a year it just refused to boot, likely due to VM OS upgrades and incompatibilities.

So I set it to latest and wasn’t aware of the major version transition or impacts. It just chugged along until it broke.

I’ll think through this but perhaps the right approach is to open a ticket with Elestio and request e.g. a “latest 1.x” option so it doesn’t auto-upgrade on major releases.

6

I would definitely consider taking the time now to move everything to a recent v2 deployment. This will bring a lot of changes with it, but you will definitely have a more future proof setup and more features.

7

I just upgraded to 2.3.6 from 1.22 and faced the same issue: “Unrecognized node type: n8n-nodes-base.start” in my docker logs.

I had 2 Start nodes (the ones deprecated in V2) on archived workflows, and I didn’t bother removing them before upgrading. What is strange with these n8n-nodes-base.start errors, is that they happened on some of my workflows without a start node, including a simple workflow Webhook→SetNode→TelegramNode, for which the webhook stopped responding.:

...
n8n-1  | Try to activate workflow "06. MyWorkflow06 (\webhook\wf06)" (6)
n8n-1  | Unrecognized node type: n8n-nodes-base.start
n8n-1  | Activation of workflow "06. MyWorkflow06  (\webhook\wf06)" (6) did fail with error: "Unrecognized node type: n8n-nodes-base.start" | retry in 256 seconds
n8n-1  | Error in handling webhook request GET /webhook/wf02: Unrecognized node type: n8n-nodes-base.start
n8n-1  | Error in handling webhook request GET /webhook/wf02: Unrecognized node type: n8n-nodes-base.start
n8n-1  | Error in handling webhook request GET /webhook/wf02: Unrecognized node type: n8n-nodes-base.start
...

Without guaranteeing reproducibility, what made the errors go away was:

  • run problematic WF with a Manual Trigger node –> success
  • run problematic WF with webhook with the webhook-test link → success
  • upgrade webhook node (from 2 to 2.1 I think) → whatever
  • Disable and re-enable workflow → The green tick for disabling didn’t want to disable. I restarted the container, and then I could disable the workflow
  • Enable/Disable the workflow, publish the workflow → success
  • Call the workflow webhook from outside → success, finally!

Unrelatedly, I also faced issues with the binary write node, which were quickly fixed by adding N8N_RESTRICT_FILE_ACCESS_TO=/myfolder1;/myfolder2 , without changing my docker volume mount declarations from the full path: ${DATA_FOLDER}/myfolder1/:/myfolder1