n8n Task Request Timed Out After 60 Seconds: How to Fix

Here's the full text n8n gives you:

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

Since n8n 2.0, Code node scripts don't run inside the n8n process. n8n acts as a task broker on port 5679. A separate task runner (JavaScript or Python) connects to it, offers to take work, and runs your code. When a Code node fires, n8n posts a task request and waits for a runner to accept it. That wait is capped by N8N_RUNNERS_TASK_REQUEST_TIMEOUT, which defaults to 60 seconds.

So the 60 seconds is a waiting room timer, not a runtime limit. When I set the variable to 20, the same error said "waited 20 seconds". Nothing about your JavaScript is being measured yet.

No, and mixing them up sends people in the wrong direction. I forced both to see them side by side:

• Task request timed out after N seconds: no runner took the task. Controlled by N8N_RUNNERS_TASK_REQUEST_TIMEOUT (default 60). This is a plumbing problem.
• Task execution timed out after N seconds: a runner took the task and your code ran past N8N_RUNNERS_TASK_TIMEOUT(default 300). I got this one by running a 15-second busy loop with the limit set to 5: "Task execution timed out after 5 seconds". This is a code or data size problem.

If you're seeing the second one, batch your input, move heavy work out of the Code node, or raise the task timeout. The rest of this post is about the first.

The setup was a two-service Compose file on my Mac mini: n8nio/n8n:2.38.3 in external runner mode and an n8nio/runners:2.38.3 sidecar, plus a two-node workflow (Manual Trigger into a Code node) run with n8n execute. Then I changed one variable at a time:

• Broker left on its default address (127.0.0.1): Code node timed out. Runner log repeated Waiting for task broker to be ready... and never moved on.
• Broker on 0.0.0.0, wrong auth token on the runner: Code node timed out. Runner log said Task broker is ready, then went silent. No error, no 401 in the log.
• Broker on 0.0.0.0, matching tokens: Code node returned { ok: true }. Runner log showed Fetched grant token for runner then Task ready for pickup, launching runner...

The wrong-token case is the nasty one: the launcher reports the broker as ready and then just never gets work. If you only check that the runner "connected", you'll miss it. Look for the grant token line instead.

Start with docker compose logs runners (set N8N_RUNNERS_LAUNCHER_LOG_LEVEL=debugon the runners container if it's quiet) and match what you see:

• "Waiting for task broker to be ready..." on repeat:the runner can't reach port 5679. Listen address, wrong hostname in the broker URI, or different Docker networks.
• "Task broker is ready" and nothing after it: check the auth token on both sides, character for character. Watch for quotes and trailing whitespace from .env files.
• Grant tokens fetched, runner starts, then errors or restarts: the runner itself is failing. Usually memory (big item arrays) or a version mismatch.
• Logs look healthy but only some executions time out: capacity or queue mode topology, covered below.

1. The broker only listens on localhost

N8N_RUNNERS_BROKER_LISTEN_ADDRESS defaults to 127.0.0.1. That works when the runner is a child process, and fails the moment it's a separate container. This is the most common cause I see after people copy an old compose file. Set it to 0.0.0.0and don't publish 5679 to the host; the runner reaches it over the Docker network.

2. The auth token doesn't match

N8N_RUNNERS_AUTH_TOKEN must be identical on n8n and on the runners container. Generate it once (openssl rand -hex 32) and reference the same variable in both services.

3. The broker URI points at the wrong place

The runner's N8N_RUNNERS_TASK_BROKER_URI defaults to http://127.0.0.1:5679, which inside the runners container is the runners container. Use the n8n service name: http://n8n:5679. On Kubernetes with a sidecar in the same pod, localhost is actually correct.

4. Queue mode workers have no runner

In queue mode the Code node executes on a worker, and each worker is its own broker. The n8n task runner docs are explicit: every worker needs its own runners sidecar, and the main instance needs one too if OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=false. The classic symptom is "works when I test in the editor, times out in production": the manual run had a runner, the worker didn't. If you're scaling workers the way I described in my n8n queue mode setup, scale the sidecars with them.

5. Image versions don't match

n8nio/runners must be the exact same version as n8nio/n8n. Pinning n8n to a version while leaving the runner on latest(or the reverse) works until the next release and then doesn't. Pin both from one variable.

6. The runner is busy or crashing

A runner accepts N8N_RUNNERS_MAX_CONCURRENCY tasks at once (default 5). Ten parallel executions with slow Code nodes means five wait, and if they wait more than 60 seconds you get this error with a perfectly healthy setup. This is the one case where raising N8N_RUNNERS_TASK_REQUEST_TIMEOUT or concurrency is the right fix. If the runner is being killed instead, give it memory with N8N_RUNNERS_MAX_OLD_SPACE_SIZE and stop passing 50,000 items into one Code node; loop over batches.

This is the shape that passed in my test, trimmed to what matters for runners:

services:
  n8n:
    image: n8nio/n8n:2.38.3
    environment:
      - N8N_RUNNERS_MODE=external
      - N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0
      - N8N_RUNNERS_AUTH_TOKEN=${RUNNERS_TOKEN}
      # optional: only if healthy runners are queuing
      # - N8N_RUNNERS_TASK_REQUEST_TIMEOUT=120

  runners:
    image: n8nio/runners:2.38.3   # same version as n8n, always
    environment:
      - N8N_RUNNERS_TASK_BROKER_URI=http://n8n:5679
      - N8N_RUNNERS_AUTH_TOKEN=${RUNNERS_TOKEN}
      - N8N_RUNNERS_LAUNCHER_LOG_LEVEL=debug   # drop once it works
    depends_on: [n8n]

Two notes. N8N_RUNNERS_ENABLEDis deprecated from 2.0, so you don't need it. And Python allowlists (N8N_RUNNERS_STDLIB_ALLOW, N8N_RUNNERS_EXTERNAL_ALLOW) go in the runners config file as env overrides, not on the container. Putting them on the container is a separate, quieter way to break Python Code nodes.

Internal mode, where n8n launches the runner as its own child process, is deprecated from n8n 3.0 and n8n now logs a warning at startup when you're on it, even if you never set N8N_RUNNERS_MODE. Most self-hosters will move to external runners over the next few months, and almost every one of them will meet this error on the first try because the defaults (127.0.0.1 on both sides) are built for internal mode.

My own production instance on the Mac mini is still on internal mode as I write this. It's on the list right after the 3.0 work I covered in the n8n 3 breaking changes post. Do the runner move as its own change, not in the same deploy as the version bump, so that if Code nodes start timing out you know which change did it.

On n8n Cloud you can't touch any of this. If Cloud Code nodes time out for days, it's a support ticket, and it's one more input for the cloud vs self-hosted decision.

1. Read the error: "request" (no runner) or "execution" (code too slow)?
2. docker compose logs runners: waiting for broker, ready but silent, or crashing?
3. N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0 on n8n and every worker.
4. Broker URI uses the service name; one sidecar per worker, pointed at that worker.
5. Same auth token, same image version on both sides.
6. Only then: concurrency, memory, request timeout.

If the workflow behind the Code node is also a webhook endpoint, check the Respond to Webhook timeout too. A 60-second runner wait will blow through most callers' HTTP timeouts before n8n even reports an error.

If you're moving a production n8n to external runners or queue mode and want it done without a week of timeouts, tell me what you're running. I'll tell you what I'd change first.