I would not treat the EU-West volume banner as the primary explanation here. The services you listed are in us-east4-eqdc4a, not EU-West. Also, volume degradation would normally show up as slow or erroring Postgres I/O inside the Postgres service; your symptom is n8n timing out while opening a client connection, with Postgres only showing checkpoints.

The first thing I would verify is the n8n DB environment. n8n defaults to SQLite and for Postgres expects explicit variables like:

DB_TYPE=postgresdb

DB_POSTGRESDB_HOST=${{Postgres.PGHOST}}

DB_POSTGRESDB_PORT=${{Postgres.PGPORT}}

DB_POSTGRESDB_DATABASE=${{Postgres.PGDATABASE}}

DB_POSTGRESDB_USER=${{Postgres.PGUSER}}

DB_POSTGRESDB_PASSWORD=${{Postgres.PGPASSWORD}}

Make sure the host is the Railway internal host for the Postgres service, not localhost, and not a stale public TCP proxy host or port unless you intentionally want the public proxy path. Railway private networking expects services in the same project and environment to resolve SERVICE_NAME.railway.internal; Railway Postgres exposes PGHOST and PGPORT for this.

Quick isolation path:

1. Redeploy n8n after fixing variables.
2. Restart Postgres once if the service has been up since the incident banner appeared.
3. If it still times out, run a TCP-only test from the n8n container to the exact host and port in DB_POSTGRESDB_HOST and DB_POSTGRESDB_PORT.
4. If TCP connects but n8n still fails, raise DB_POSTGRESDB_CONNECTION_TIMEOUT temporarily and check Postgres connection count or pool size.

If Railway support needs to verify platform state, the useful evidence is not the EU-West banner but: resolved host, target port, n8n region, Postgres region, and whether a raw TCP connect from n8n to Postgres succeeds. That will separate private-network, DNS, or env problems from a database volume incident.