I’m experiencing a systematic issue on my n8n Cloud instance: all Code nodes fail with “Task request timed out” (60s), indicating the task runner cannot service requests.
Replaced the original business logic script with a trivial one: return [{json:{test:1}}]; → same timeout. Not a script issue.
Created a brand new, empty workflow with a single Code node → same timeout. Not specific to one workflow, affects the whole instance/account.
Checked status.n8n.io → “All systems operational”. Not a general n8n Cloud outage.
Enabled “Retry On Fail” (5 attempts, 1s interval) → failed on all 5 attempts. The runner appears continuously unavailable, not just occasionally busy.
Error message:
“Task request timed out - 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.”
Note: an earlier execution (Sept 9, 09:16:57) stayed stuck in “Running” state for 7h54m before erroring out, which seems related.
Since I’m on n8n Cloud, I don’t have access to N8N_RUNNERS_TASK_REQUEST_TIMEOUT or any runner infrastructure settings myself. This is blocking a production stock sync between an ERP (Cegid) and a WooCommerce store, running every 25 minutes. I would appreciate your help checking the health of the task runner(s) assigned to my instance.
I already reported this on GitHub (n8n-io/n8n) and was redirected here since it’s account/instance-specific rather than a code bug.
Hi @Iheb_Tliba Welcome!
That instance is not n8n Cloud. Cloud workspaces live on app.n8n.cloud, while n8n-wsk.com is WebSpaceKit’s managed n8n hosting, so status.n8n.io and n8n support cover nothing there and the runner that times out runs inside WebSpaceKit’s container.
The message with a trivial script on a fresh workflow means the task broker has no runner connected. In the default internal mode n8n launches the runner as a child process, and when that child keeps dying, memory pressure on a small plan being the usual reason, every task waits the full 60 seconds and fails, which also fits the run that sat at Running for 7h54m. Retry On Fail only hits the same missing runner.
Open a ticket with WebSpaceKit and ask them to restart the n8n container and check three things: the container’s memory limit and whether the runner child is being OOM-killed, the value of N8N_RUNNERS_MODE, and the n8n version under Help > About n8n. If that version reads 2.37.1, it is the release that broke the JavaScript Code node and 2.37.2 carries the fix. Task runners | Deploy | n8n Docs
The detail that stands out is that a trivial Code node also times out, so this does not look like a stock-sync script problem by itself. It sounds more like the Code task runner is not servicing requests, or the runner process/container is failing before the workflow logic gets a chance to matter.
I would separate the investigation into two parts before changing the WooCommerce/Cegid workflow: one recent failed execution window, and the runner/hosting evidence around that same time. If the runner is the first thing failing, rebuilding the stock-sync logic may just hide the real issue.
If you still have the problem, the useful evidence would be the failed execution timestamp, hosting/runtime logs around that minute, and whether a fresh workflow with only return [{ json: { test: 1 } }]; still fails.