Database timeout
jonathandantaschagas
PROOP

17 days ago

I have a database connected to n8n.

And the database is constantly timing out.

This is causing instability and problems in n8n, which has critical processes.

I need your help to solve this problem as soon as possible. Otherwise, I will have to migrate my apps and services.

$20 Bounty

4 Replies

Railway
BOT

17 days ago

This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.

Status changed to Open Railway 17 days ago


jonathandantaschagas
PROOP

17 days ago

Logs


What is the state of your Postgres database? Can you share more information about it?


darseen

What is the state of your Postgres database? Can you share more information about it?

jonathandantaschagas
PROOP

17 days ago

Its status is active.

It was working normally until the weekend, when it started experiencing this problem.


adaptive-ap
PRO

17 days ago

Does restarting the n8n service alone fix it, even temporarily?

  • Yes → stale DNS / dead connection pool. Confidence on that cause jumps to ~80%.
  • No → rules out the #1 hypothesis entirely. Forces focus on Postgres-side or platform.
  • This is the highest-information question because it's binary and cheap to test.

Paste the DATABASE_URL host (redact username/password) — does it end in .railway.internal or is it a *.proxy.rlwy.net / public TCP address?

  • .railway.internal → private networking, DNS/pool theory stays live.
  • Public proxy → that's likely the problem on its own; public proxy adds latency and has stricter idle timeouts. Switching to private networking often fixes it outright.

Screenshot the Postgres service's Metrics tab — CPU, memory, disk, and active connections over the last 7 days.

  • Connections pinned at limit → n8n is leaking, needs pool cap.
  • Disk at 100% → Postgres is read-only, that's the real issue.
  • CPU/memory spike starting over the weekend → resource exhaustion, needs a bigger plan or query investigation.
  • Flat and healthy → rules out DB-side resource issues, points at networking/platform.

Welcome!

Sign in to your Railway account to join the conversation.

Loading...