GCP: Postgres connection timeout during n8n startup on Cloud Run (Cloud SQL Unix socket)

Questions
1

Description
We observed a one-time startup incident in n8n on Google Cloud Run with PostgreSQL on Cloud SQL (Unix socket connection).

Environment

  • n8n version: 2.32.5
  • Runtime: Google Cloud Run (Gen2)
  • Region: europe-west3
  • Database: PostgreSQL on Cloud SQL
  • Connection method: Unix socket under /cloudsql

What happened

  • During one startup window, n8n logged repeated:
    • Error: timeout exceeded when trying to connect
    • stack traces pointing to pg-pool, @n8n/typeorm, and @n8n/db connection acquisition paths.
  • In that same window:
    • root endpoint could return 200
    • some API calls returned 500 / high latency
    • DB-dependent background tasks reported failures
  • A manual redeploy was performed.
  • Shortly after redeploy, the service stabilized and has worked normally since.
2

Hey @rgrzesk, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@Mayank1024, @Websensepro, @tamy.santos - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

3

Hi @rgrzesk It looks like your just reporting a bug, correct? Your instance is all good now?

4

@rgrzesk

Looks more like an incident report to me.
Perhaps you would like to raise the issue with your provider

5

Hi @rgrzesk
“timeout exceeded when trying to connect” comes from pg-pool’s acquisition timeout, so the pool never handed out a client within DB_POSTGRESDB_CONNECTION_TIMEOUT, rather than the Cloud SQL socket being unreachable. DB_POSTGRESDB_POOL_SIZE defaults to 2, and on a single Cloud Run instance the startup queries plus incoming traffic queue behind those two connections, which is why the root endpoint stayed 200 while the DB-backed calls went 500. Raise both on the revision:

DB_POSTGRESDB_POOL_SIZE=10
DB_POSTGRESDB_CONNECTION_TIMEOUT=60000

Then cap Cloud Run container concurrency to roughly what the pool can serve (10 to 20), so a spike can’t outrun it again. Cloud Run allows 100 connections per instance to Cloud SQL, so 10 stays well inside that.

6

I’m glad the service has stabilized and has been operating normally ever since :slight_smile:

7

Thanks! I will tune the CloudRun this way.
However, what worries me - it just happened all of a sudden and the instance is up from 6 months, so far working without any issues.

8

A pg-pool acquisition timeout tells you that no client became available before the deadline. It does not prove the pool was too small. Because this happened once after six stable months, raising the pool may only move pressure to Cloud SQL.

Line up the affected revision with the Cloud SQL connection graph and the Cloud Run startup log for that timestamp. If both existing connections were busy while requests queued, a larger pool or lower container concurrency is reasonable. If new connections were timing out, the pool size is not the root cause.

Change one limit at a time and keep the previous value recorded. Otherwise the next incident will not tell you which change helped.