The n8n error that hides its own fix from Cloud users

Same failure, two different error messages

When a Code node cannot get hold of a task runner, n8n tells you so:

Your Code node task was not matched to a runner within the timeout period (waited 60 seconds). This indicates that the task runner is currently down, or not ready, or at capacity, so it cannot service your task.

Then it offers advice. On a self-hosted instance the advice includes the setting that raises the limit, named exactly: an environment variable called N8N_RUNNERS_TASK_REQUEST_TIMEOUT. On Cloud that sentence is not shown, because the code that builds the message appends it only when the deployment is not Cloud.

The same pattern runs through the other two runner errors. The 300-second execution timeout names its own variable to self-hosted users and not to Cloud ones. And when the runner runs out of memory, the suggestion "increase the memory available to the task runner" is swapped for "Upgrade your cloud plan to increase the available memory".

What is a task runner?

A separate process that executes the code you write in a Code node. n8n describes the arrangement plainly:

Task runners are a generic mechanism to execute tasks in a secure and performant way. They're used to execute user-provided JavaScript and Python code in the Code node.

A task requester submits a task request to the broker where an available task runner can pick it up for execution. [...] The n8n instance (main and worker) acts as the broker. The Code node in this case is the task requester.

• Set up task runners, n8n Docs

So your Code node does not run your code. It asks a broker to find something that will. That is why a Code node can fail while every other node in the workflow is fine, and why the failure is about availability rather than about your script.

The same page explains why the architecture is built this way at all:

Task runners are the only isolation layer between user-provided code and n8n.

• same page, n8n Docs

Which timeout did you hit?

Two different ones, with two different meanings. The documented defaults:

Quotes and defaults: Task runner environment variables, n8n Docs.

The sixty-second one means your script never started. The three-hundred-second one means it started and did not finish, and its message says so:

Task execution timed out after 300 seconds. The task runner was taking too long on this task, so it was suspected of being unresponsive and restarted, and the task was aborted.

• as pasted by a self-hosted user, n8n Community, 4 August 2026

That report is from a self-hosted instance, and it is worth reading for the contrast: his copy of the message goes on to name the environment variable that raises the limit. A Cloud user hitting the same wall gets the same first sentence and not that one.

Which one you got changes the whole diagnosis. Waiting means contention or a sick runner. Timing out means your task, and the next section is about a common reason a small script takes five minutes.

One caveat worth stating: these are the documented defaults for a self-hosted deployment. Nothing in n8n's documentation states the values used on Cloud, and the runner pages do not mention Cloud at all. They match what people observe, but observation is what they are.

Why is the first Code node in a run so much slower?

Because an idle runner shuts down, and the next task has to wait for one to start. A Cloud user measured it carefully:

the FIRST Code node executed in a run costs ~1.6 seconds when the instance has been idle for roughly 15 seconds or more. Every Code node executed after it, in the same run, costs 3-7 ms. Set nodes show no penalty at all.

• a user, n8n Community, 15 August 2026

That number lines up with the fifteen-second idle shutdown in the documentation, though the person measuring it was careful to say he could not confirm Cloud uses that value. What it means in practice: a workflow that runs once an hour pays the cold start every time, and one that runs constantly does not. If your webhook handler feels slow and the Code node is the first thing it does, this is a likely cause and it has nothing to do with your script.

What can a Cloud owner actually change?

Nothing about runners, and it is worth being direct about that. The Cloud configuration page lists four things: timezone, IP addresses, data management, instance ownership. The concurrency page that sounds relevant is about executions, not runners, and scopes itself:

Concurrency control applies only to production executions: those started from a webhook or trigger node. It doesn't apply to any other kinds, such as manual executions, sub-workflow executions, or error executions.

• Understand concurrency, n8n Docs

A community moderator has answered the question repeatedly, in the same terms:

On Cloud you can't change the runner env vars yourself, so the one thing you can do from your side is reduce how many Code and AI Transform nodes hit the runner at once: space out heavy or parallel executions instead of firing many at the same time.

• a community moderator, n8n Community, 9 July 2026

And when a member of the n8n team answered the general question about changing environment settings on Cloud, back in 2025, the answer was a higher plan or a conversation with the enterprise team. That is the honest list of levers: fewer concurrent Code nodes, a larger plan, a support ticket, or no Code node at all.

The trap that spends the whole 300 seconds

One cause of the execution timeout is worth knowing because it looks like nothing. Referring to another node by name inside a Code node makes the runner ask for the serialized workflow and resolve every node type in it. If one type cannot be resolved, the request never returns, and the watchdog kills the task five minutes later.

The fix, from the thread where it was diagnosed, is a rewrite and not a setting. Use only the current item and its input inside the Code node, and put anything you need from an earlier node onto the main path with a Set node first.

When it is not the runner at all

A Cloud user spent a week on slow Code nodes, and the resolution had nothing to do with code:

There were some old workflows that were stuck between published and unpublished due to a recent update [...] the system tried to rerun them in an infinite loop [...] causing a growing strain on the CPU making the platform unusable. Once the workflows were manually unpublished, everything went back to normal.

• the person who reported it, after working with support, n8n Community, 4 September 2026

Before that resolution, the same person measured a two and a half second execution that contained 227 milliseconds of node time and no Code node at all. The lesson generalises: when the slowness is instance-wide, look for something else on the instance eating it, and check whether workflows you thought were off are running.

Python and JavaScript fail separately

They are two different runner processes, and it shows. On one self-hosted instance JavaScript was fine while Python timed out after a few hours of working; on a Cloud instance a one-line Python script timed out while JavaScript in the same workflow ran normally. Both point the same way, which is itself worth knowing if your Python nodes are the ones failing.

So "the Code node is broken" is worth narrowing before you report it. Also worth knowing for Cloud specifically, from the documentation: the Python option there does not allow importing any Python libraries, standard library included.

Removing the dependency

The most reliable fix is to stop asking for a runner. n8n's own advice, in its guidance on memory problems, is blunt: "Avoid using the Code node where possible." Most Code nodes in small business workflows are doing something a built-in node does, and here is the mapping, in n8n's words:

Descriptions of Aggregate, Limit, Remove Duplicates, Sort, Split Out and Summarize: Expressions versus data nodes, n8n Docs. The Edit Fields and Filter descriptions come from those nodes' own documentation pages.

A workflow rebuilt this way does not wait for a runner, does not pay the cold start, and cannot hit either timeout. It is usually also easier for the next person to read, which matters more than it sounds when the next person is you in a year.

If every Code node broke on the same day

That is a different story with a different cause. In late August 2026 a release broke the JavaScript runner outright for everyone who received it, and the fix was a version change rather than anything about your workflow. If your failures started overnight and hit every Code node at once, read that one instead.

The failures in this article are the ordinary kind: they come and go with load, they hit some runs and not others, and they have been reported steadily all year, not on one bad morning.

What to do about it

1. Read which error you got. Sixty seconds waiting is contention. Three hundred seconds is your task. They lead to different places.
2. Check whether the first Code node in the run is the slow one. If so, the cold start explains it, and moving that work into a Set node removes it.
3. Count how many Code nodes run at once across all your workflows, not just the one you are looking at. They share the runner.
4. Rewrite Code nodes that reach for other nodes by name, so they use only their own input, with anything else brought onto the main path first.
5. Replace what can be replaced with the nodes in the table above. This is the only change on the list that removes the dependency rather than managing it.
6. If it is instance-wide, look past the Code node. Stuck or duplicated workflows can eat the instance, and that shows up as everything being slow.
7. On Cloud, open a support ticket when the runner itself is sick, because nobody else can reset it. Say which timeout you hit and include an execution id.

When this is a job to hand over

Swapping one Code node for a Set node is a small change, and if you can see which node is slow, make it yourself.

It becomes a job when a dozen workflows share the same runner and nobody knows which ones are heavy, when the timeouts started after a workflow you did not write was published, or when the rewrite means untangling a Code node that has grown into the place where all the business logic lives. That kind of job starts as an inventory - which workflows, which nodes, how often they fire - and the price is agreed off the inventory. Fix S and Fix M are sized that way.

Sources

• Set up task runners - n8n Docs, read 6 September 2026. What a task runner is, the broker and requester roles, and runners as the only isolation layer between user code and n8n.
• Task runner environment variables - n8n Docs, read 6 September 2026. The sixty-second request timeout, the three-hundred-second task timeout, and the fifteen-second idle shutdown, with their documented defaults. The page does not mention Cloud.
• Understand concurrency - n8n Docs, read 6 September 2026. Concurrency control applying only to production executions.
• Expressions versus data nodes - n8n Docs, read 6 September 2026. The descriptions of Aggregate, Limit, Remove Duplicates, Sort, Split Out and Summarize used in the replacement table.
• Fix memory issues - n8n Docs, read 6 September 2026. The advice to avoid using the Code node where possible.
• n8n-io/n8n - n8n source, read 6 September 2026. The three runner error messages, the branch that appends the environment variable suggestion only for self-hosted deployments, the substitution of a plan upgrade for the memory variable on Cloud, and the runner configuration defaults.
• Community thread 302716 - n8n Community, 9 July 2026, read 6 September 2026. A moderator explaining that Cloud users cannot change runner variables and can only space out their Code nodes.
• Community thread 307804 - n8n Community, 15 August 2026, read 6 September 2026. The measured cold start on the first Code node of a run, and the reporter's own caveat about what he could not verify.
• Community thread 306079 - n8n Community, 4 August 2026, read 6 September 2026. The three-hundred-second timeout message, and the diagnosis that referring to another node by name inside a Code node can hang the request.
• Community thread 309210 - n8n Community, 24 August to 4 September 2026, read 6 September 2026. A week of slow Code nodes resolved as workflows stuck between published and unpublished, looping and consuming the instance.