N8N errors after shifting to V2

Questions
, ,
1

Describe the problem/error/question

We were using the n8n version 1.118.2 on a VM and now have switched to version 2.11 on GCP Cloud run. Ever since the switch we’ve been facing so many problems and if one thing is resolved the other comes up.

Problems:

  • N8N workflows would timeout again and again

    • Found out it was because in the new version we need to enable the N8N_RUNNERS_ENABLED=true
      N8N_RUNNERS_MAX_CONCURRENCY=5
      N8N_RUNNERS_TASK_REQUEST_TIMEOUT=300

      After adding the above envs the timeout error stopped happening.

  • N8N workflows are taking a lot of time.
    • Earlier the requests would take max 600-750ms but now there are a few requests which are taking more than 5mins and then it errors out.
    • There was even one workflow which had been running for 15Hrs !!!

Errors:

- last executed node:  Code in JavaScript

message: Task request timed out after 300 seconds

description: 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.<br/><br/>If you are repeatedly executing Code nodes with long-running tasks across your instance, please space them apart to give the runner time to catch up. If this does not describe your use case, please open a GitHub issue or reach out to support.<br/><br/>If needed, you can increase the timeout using the N8N_RUNNERS_TASK_REQUEST_TIMEOUT environment variable.

- last executed node:  Google firestore db

message: The connection to the server was closed unexpectedly, perhaps it is offline. You can retry the request immediately or wait and retry later.

description:

Information on your n8n setup

  • n8n version: 2.11
  • Database (default: SQLite): Postgres
  • n8n EXECUTIONS_PROCESS setting (default: own, main): default
  • Running n8n via (Docker, npm, n8n cloud, desktop app):Docker
  • Operating system: GCP Cloud Run
2

hello @Punosie

keep in mind that you should specify a custom health endpoint for GCP

image
image1236×226 25.4 KB

Google Cloud Run | n8n Docs.

Usually the migration to another platform should be perform in the next steps:

  • migration of the current version
  • updating to the new version

Otherwise, it will be difficult to track the root cause

3

Hi @Punosie

I think the main issue here is not “v2 is slower” by itself, but that your Cloud Run deployment likely isn’t sized or structured yet for task runners, which are required for Code node execution in v2 and are recommended in external mode for production. On Cloud Run, I’d first verify runner health/capacity and whether you’re using a proper runner setup, because that specific timeout means tasks are waiting for an available runner rather than failing inside the Code node itself.
Since you also moved from a VM to Cloud Run at the same time, I’d treat this as a deployment-architecture issue first and share your Cloud Run CPU/memory/concurrency settings plus the exact runner mode you’re using.

If you want, post the relevant env vars and one affected workflow path, because that should make it easier to tell whether this is runner starvation, Cloud Run sizing, or a separate Firestore/network problem.

1 Like
4

Okay thanks, I’ll look into it

1 Like