Cloud: task runner down for 7+ hours, every Code node times out after 66s

Questions
1

Describe the problem/error/question

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.
Instance: brunoclozel.app.n8n.cloud
Plan: trial, 6 days left, 113/1000 executions used
Timeline:

  • 03:00 UTC - last successful execution (id 131)
  • 06:00 UTC onwards - every scheduled workflow fails (ids 132 to 138)
  • 12:50, 12:57, 13:03 UTC - manual retries, same failure (ids 142, 143)
    Nothing changed on my side between the last success and the first failure.
    These are small scheduled workflows that had been running fine for 9 days.
    The important detail: workflows WITHOUT a Code node still execute normally.
    An error-handler workflow made only of an Error Trigger and a Telegram node
    completed in 0.4s at 13:04 UTC (id 144), on the same instance, at the same
    time the others were timing out. So the failure is isolated to the task
    runner, not to my workflows and not to the instance as a whole.
    I am not running long or bulk Code tasks - the node in question builds a
    short string from ~10 rows of a Data Table and returns in ~20ms when the
    runner is healthy.
    status.n8n.cloud reports no incident.

What is the error message (if any)?

Please share your workflow

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.

Stack:
Error: Task request timed out
    at LocalTaskRequester.requestExpired (task-requester.ts:310:17)
    at LocalTaskRequester.onMessage (task-requester.ts:276:10)
    at TaskBroker.handleRequestTimeout (task-broker.service.ts:179:50)

Share the output returned by the last node

Last node executed: the Code node. It produced no output.
The node immediately before it (Data Table, get rows) returned its rows
normally, so the chain is healthy up to the point where the Code node hands
off to the runner.

Information on your n8n setup

  • n8n version: n8n Cloud (managed, auto-updated)
  • Database (default: SQLite): n8n Cloud managed default
  • n8n EXECUTIONS_PROCESS setting (default: own, main): n/a - n8n Cloud
  • Running n8n via (Docker, npm, n8n cloud, desktop app): n8n cloud
  • Operating system: n/a - n8n Cloud
2

Hi @Bruno_Clozel Welcome!
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. Open the Cloud dashboard, go to Manage > Workspace > Updates & maintenance, set Release track to Stable, pick 2.36.7 in the n8n version dropdown and select Change version. It restarts the workspace for a minute or two.

3

Your testing strongly points to a task-runner issue rather than a workflow or Data Table problem. Since workflows without Code nodes are still running normally and the same Code node works when the runner is healthy, the 66-second timeout appears to happen while waiting for a runner to accept the task.

The fact that manual retries show the same behavior also makes a temporary workflow-level failure less likely.

4

Thank you, that is exactly it. 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.

Just switched: Release track Beta → Stable, version 2.36.7. Workspace is
restarting now. I will report back here whether the Code nodes recover, so
this thread has a confirmed answer.

One note for anyone finding this later: 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. The only visible symptom
was every Code node timing out after exactly 66 seconds while workflows
without a Code node kept running normally in under a second.

Also worth flagging to the team: 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.