fixmation.Get my quote
n8n17 min readPublished September 2026

Nobody touched it and it broke: n8n Cloud upgrades itself overnight

A Cloud workspace on the fastest update cadence takes each new release the moment it ships, on average one a day. One of them broke every JavaScript Code node in late August, and the people it hit had not chosen to be on that release at all.

Seven hours of failures and nobody deployed anything

The report is precise about everything except the cause. Production runs that worked yesterday now fail after the same interval, the failure lands on one node type, and the person who owns the instance has changed nothing:

Since 2026-08-26 06:00 UTC, every production execution on my Cloud instance that contains a Code node fails after exactly 66 seconds. The Code node never gets matched to a task runner.

Nothing changed on my side between the last success and the first failure.

The important detail: workflows WITHOUT a Code node still execute normally.

The error the editor showed pointed at infrastructure, which is exactly why several people spent the morning trying to fix infrastructure they do not control:

Task request timed out / Your Code node task was not matched to a runner within the timeout period (waited 66 seconds). This indicates that the task runner is currently down, or not ready, or at capacity.

  • the same user, same thread, n8n Community, 26 August 2026

Four separate threads were opened on 26 August, from six in the morning to half past one in the afternoon UTC, and more followed the next day. The same break arrived on GitHub as more than a dozen issues that day alone, from a dozen different accounts, which a maintainer closed as duplicates against a single pull request. One of the teams reporting it the next day had already spent money on the wrong diagnosis:

We initially thought this might be some sort of limitation on the free tier, so we upgraded to a paid n8n Cloud subscription. Unfortunately, the exact same issue persists.

What actually happened to the instance

The instance changed version overnight. A community moderator put it in one sentence in a different thread about a different broken node, six days earlier:

Nothing changed on your side, the workspace picked up a new release on its update track, which you can set under Manage > Workspace > Updates & maintenance.

The first thread about the Code node failures went up at half past six that morning, and the moderator's first answer to it named neither a release nor a track. By the fourth thread, seven hours later, he had the cause and posted it within seven minutes:

The runner is not down, 2.37.1 breaks the JavaScript Code node, so there is nothing on your instance to reprovision.

2.37.1 is the Beta track and 2.36.7 is the current Stable, so the version you want is lower than the one you are on.

And the person who reported it worked out the part that matters for everyone else:

I was on the Beta track without realising it, with update cadence set to "Every new release", so I got 2.37.1 as soon as it shipped.

  • the thread's author, same thread, n8n Community, 26 August 2026

Another affected team said the same thing in their own thread: "Nobody here chose beta deliberately, so that explains a lot."

Why the status page stayed green

Because no incident was declared. An upgrade is a planned event, and planned events do not go on the status page:

A Cloud workspace on Update cadence "Every new release" with Maintenance window "Upgrade anytime" takes each release the moment it ships, on average one a day, and every upgrade is a 1 to 2 minute restart where the editor goes down. A scheduled upgrade is not an incident, so the status page stays green through it.

That quote is about the short editor outages that look like a flaky connection. The same moderator said the same thing about the day the Code node broke:

2.37.1 breaks the JavaScript Code node, which is why a bare return fails exactly like a real script does and why the status page looks clean

Customers watching the page saw exactly that:

status.n8n.cloud stayed green and 100% the whole time, and the Cloud Overview showed the instance as healthy. Nothing on my side indicated a problem.

One caveat on that evidence, since it matters for how much weight to put on it: status.n8n.cloud does not serve a retrievable history for those days, so what the page displayed on 26 August rests on what customers and the moderator said about it, not on a record anyone can pull up now.

A green status page is a statement about incidents, not about your workspace. If your instance took a release ten minutes ago, the page has nothing to report and your workflows can still be broken.

The four settings that decide when your instance changes

All four live in one panel, and none of them is visible from the workflow editor where you spend your day. The wording below is n8n's own.

SettingOptions, verbatim from the docsWhat it decides
Release track"Beta: new releases delivered as soon as they're ready." / "Stable: a later, more proven patch of a release, cut after it's spent time on the Beta track. n8n recommends Stable for all mission-critical workloads."Which stream of builds you are eligible for
Update cadence"Security & stability: upgrades about every two weeks." / "Every new release: upgrades to each new release as it ships, on average one release per day."How quickly a build from that stream reaches you
Maintenance window"Upgrade anytime: n8n applies upgrades as soon as they're available." / "Pick a window: n8n only applies upgrades during the time range you set."What time of day the restart happens
n8n version"The n8n version dropdown sets the version your workspace runs."The build you are on right now, and how you roll back

Sources for every quote in that table: Update your version, n8n Docs.

Two readings of that page matter more than the rest. The first is a clause worth memorising before you go changing things:

n8n always applies security and stability updates automatically, whichever cadence you choose.

So the cadence setting is not an off switch: the docs attach that promise to whichever cadence you choose. What the panel controls is how much exposure you take and at what hour it lands.

The second is what the page does not say. It never states which track a new workspace starts on, or which cadence. So "everyone is on Beta by default" is not something anyone can honestly claim - what the threads establish is that several teams were on Beta with the fastest cadence and did not know it. Which one of those two facts applies to you is a question you answer by opening the panel.

Where those settings live, and who can change them

The docs give the path and the restriction:

To open the settings: Log in to the n8n Cloud dashboard. Select Manage. Select Workspace to open the Updates & maintenance section.

Only instance owners can change these settings. Contact your instance owner if you don't have permission to update n8n Cloud.

Changing the version triggers a 1 to 2 minute restart. The other maintenance settings apply without a restart.

Three of the four settings are therefore free to fix right now, at any time of day. Only the version change costs a restart, and that restart is the reason to do it deliberately, at a moment when a minute of downtime costs nothing.

What the release notes would have told you

Nothing. That is not a figure of speech: n8n's changelog is organised by minor version, and 2.37.1 has no entry on it at all. The page explains its own scope:

This page is a running log of feature-level updates from each n8n release: what shipped in the editor and the integration nodes, one line per feature, newest first.

The GitHub release for the tag n8n@2.37.1, published 25 August 2026, lists exactly one change: an OAuth2 proxy fix in core. Nothing about the Code node, nothing about task runners. A careful owner who checked the release notes before and after the upgrade would have learned nothing about the thing that was about to break, because the regression was not in any listed change.

The real cause was in the container image, and it is written down in the pull request that fixed it:

The distroless runners image copies the bare node binary from node:26.5.1-bookworm-slim and stages its glibc libraries from the python builder image. Node 26 links against libatomic.so.1 (Node 24 did not). Neither the python image nor the distroless/cc-debian13 base provides that library, so the JS runner exits with code 127 on every launch and no Code node task is ever matched.

This is the same shape as every other break that arrives from a third party: the change is documented, but the document is a pull request in the vendor's repository and not a line on your dashboard. When a Cloud instance breaks the morning after an upgrade, the repository is where the answer is, and the changelog is not.

Why Python kept working while JavaScript did not

Because the missing library belonged to the JavaScript runner process, and the Python path did not touch it. That detail sent at least one team down a false trail about plan limits, and it is worth having as a diagnostic: a Code node that fails in JavaScript and succeeds in Python is not a code problem and not a plan problem. It is a broken JavaScript runner, and the version dropdown is what moves it.

The same asymmetry produced the emergency workaround, and it came from another customer rather than from n8n:

If you can't update right now, switch the Code node language to Python and you'll keep running, since it's only the JavaScript path that's broken.

Rewriting a JavaScript node in Python under pressure is a poor plan for anything long, but for a five-line transform in a workflow that has to run this afternoon, it is a real option.

The promised patch and the one that actually shipped

Staff told two threads the fix would be 2.37.2:

This will be fixed in 2.37.2 which will be available soon

There is no public release of 2.37.2. The GitHub API returns "Not Found" for that tag. The fix shipped as 2.37.3 on 27 August, and its release page carries the comparison 2.37.1...2.37.3 and the two commits that stage the missing libraries into the runners image.

Nothing sinister in a renumbered patch, but it matters if you were waiting: a person who read "2.37.2 will be available soon" and then watched the version dropdown for 2.37.2 was watching for a build that never appeared. The fix was there a day later under a number nobody had mentioned.

What the support ticket said, and what the fix actually was

The same customer used both channels and reported the difference:

I opened a ticket by email and the AI first-line reply told me "there is no self-service action available to resolve a failed or unavailable task runner" and escalated to a human with a 3-day SLA. The actual fix was a two-minute version change I could do myself. The forum got me a correct answer in minutes; the email channel sent me to wait.

Worth reading twice, because the first-line answer was not wrong about the task runner - there genuinely is nothing a customer can do to a Cloud task runner. It answered the wrong question. The lever here was the version dropdown, and the email channel never mentioned it.

Changing the version does not change what happens next

Rolling back to the last good build fixes today. It does nothing about the next release, which is where one commenter in those threads was blunter than the vendor:

switching to 2.36.7 fixes today's problem but doesn't stop the next one. Might be worth dropping the update cadence down, or just moving to Stable track unless you actually need beta features for something. Otherwise you're just going to eat whatever regression ships next too.

There is also an order-of-operations trap. One person switched the track and left the version alone:

I switched my n8n Cloud workspace from the Beta release track to Stable, allowing the instance to redeploy/restart, but the problem still persists.

The track governs what you receive next. It does not move you off the build you are already running. Both actions are needed, and n8n's own instruction has them both: set the track to Stable and change the version in the dropdown.

What to set if this instance runs anything that matters

  1. Open the panel and write down what you find. Manage > Workspace > Updates & maintenance, as the instance owner. Track, cadence, window, current version. You cannot reason about any of this from the editor, and none of it appears on the status page.
  2. Set the release track to Stable unless a beta feature is load-bearing for you. n8n's own wording: "n8n recommends Stable for all mission-critical workloads."
  3. Set the cadence to Security & stability if you were on "Every new release". You still get security and stability updates automatically - the docs are explicit that this happens whichever cadence you choose - but you stop taking every daily build the hour it ships.
  4. Pick a maintenance window outside your working hours. Upgrades restart the workspace for a minute or two, and it is better for that minute to be at 03:00 than during the morning your team is quoting jobs.
  5. Change the version only when you mean to, knowing it costs a restart. If you are rolling back, pick a build that predates the break. The newest available build is not the same thing.
  6. Write down the version you are on today. When something breaks with "we changed nothing", the first useful question is whether the version is the same as it was, and nobody can answer that from memory.
  7. Have an alert that does not depend on you looking. The whole failure mode here is silence: green status page, healthy overview, failing runs. If nothing tells you the runs are failing, the discovery time is however long until a customer complains.

When this is a job to hand over

Setting four dropdowns is not a job for anyone else. Do it this afternoon.

It becomes a job when the instance has been silently failing for long enough to have written wrong data downstream, when workflows are built on a beta feature so moving to Stable becomes a migration and not a setting, or when the answer to "what version were we on when this started" is nobody knows and the failures are intermittent. Those are finite, scoped pieces of work with a known price, which is what Fix S and Fix M are for. The related job worth doing in the same pass is the one that stops the next surprise being discovered by a customer: monitoring that watches the runs instead of the status page. Both are n8n jobs we take at a fixed size.

The other half of this problem lives on self-hosted instances, where nothing upgrades itself and the risk runs the other way - a major version that removes what your workflows are built on sits there waiting until you choose the moment.

Sources

Broken workflow? Fix S — $300, 2 business days, fixed price.

Get my quote in 24h

Written by the Fixmation team.