Hey there! We've found the following might help you get unblocked faster:

• 🧵 Postgres Database is not ready - n8n

• 🧵 {"code":503,"message":"database is not ready!"} appears in browser and can't access n8n deployment

• 🧵 PostgreSQL crashed: No space left on device, n8n workflows inaccessible"

• 🧵 Can't deploy popular n8n template

If you find the answer from one of these, please let us know by solving the thread!

do you see any error log in the db? are the credential set in the app correct?

Hi, here’s a more complete update with logs and behavior details:

• App / Env

  • n8n service: n8n-railway-custom

  • n8n version: 1.109.2

  • DB: Railway Postgres (in the same project, Docker image, restarted 4 days ago)

• Behavior

  • After redeploy, everything works fine for a while.

  • Within ~24 hours, the issue reappears:

    • 503 Database is not ready!

    • timeout exceeded when trying to connect

    • Failed to hard-delete executions

  • Redeploying again temporarily fixes it, but the cycle repeats.

• Logs

  • Deploy logs:

    timeout exceeded when trying to connect
    503 Database is not ready!
    Failed to hard-delete executions
    

  • HTTP logs: show multiple 503 responses for /home/workflows while /rest/push endpoints keep responding fine.

  • Build logs: deployment completes successfully without errors.

  • After redeploy: logs show n8n starts normally on port 8080, workflows initialize, and HTTP requests return 200/304 as expected.

• Other Notes

  • DB credentials are correct (double-checked against Railway settings).

  • No disk/memory alerts in the project dashboard.

  • This looks more like a long-running connection stability issue or possibly something related to the current n8n version on Railway.

My question: Is this a known issue with n8n 1.109.2 on Railway Postgres, or could it be related to connection pooling / idle timeouts on the Railway side?
Any guidance on how to avoid the “redeploy every 24h” workaround would be really appreciated.

We've got the exact same issue and template used. Mine started when the postgres got updated. I even had to connect to the postgres and reindex the tables.

Temporary solution I have is just restart the services. But it's now at the point where the 503 is happening once a day so it's actually getting frustrating.

I'm planning to create a new project and just migrate everything there. But what I'm suspecting is there was a recent n8n update that wasn't optimized and is causing slowness with postgres.

Now, when our n8n is trying to connect, there are logs showing "Slow database query". Then when we connect multiple times, it is timing out.

Glad I found this to know that I'm not the only one. I hope there's a fix soon because I also have workflows expected to run 24/7