2 months ago
Hi,
I’m experiencing a database connectivity issue immediately after receiving a Railway infrastructure maintenance notification.
Maintenance context:
I received an email stating that my Postgres service would be temporarily offline due to maintenance. Since then, the service does not appear to have recovered correctly.
Current state:
- Postgres logs show:
database system is ready to accept connections - However, the database is unreachable:
- Railway UI is stuck on “Attempting to connect to the database…”
- External connections (pgAdmin) fail
- Internal connections to
postgres.railway.internal:5432time out
Example error:
connection to server at "postgres.railway.internal", port 5432 failed: Connection timed out
What I tried:
- Restart
- Redeploy
No change.
This started directly after the maintenance event, so it looks like the service did not properly recover or reattach to the internal network.
Could you please investigate and restore connectivity?
Thanks!
2 Replies
Status changed to Awaiting Railway Response Railway • about 2 months ago
Status changed to Open Railway • about 2 months ago
2 months ago
This looks like a network reattachment failure after maintenance, not a Postgres issue. The log saying "ready to accept connections" means the database itself is fine, it's the Railway internal network layer that didn't recover cleanly.
Most likely cause
Railway's internal DNS or private networking didn't rebind the service correctly after maintenance. The .railway.internal hostname is part of their private network overlay, and it occasionally fails to reroute after a service interruption, leaving the container running but invisible to the network.
What to try, in order
- Don't just restart the Postgres service ,,restart every service in the project, including your app. The internal network bindings sometimes only resolve when all services renegotiate simultaneously.
- Delete and redeploy the Postgres service entirely (not just restart). This forces Railway to reassign internal networking. Make sure your volume is still attached before doing this.
- Go to your service settings and check if the private networking / internal hostname is still correctly configured. After maintenance Railway occasionally drops or reassigns these.
- Try connecting via the public TCP proxy instead of the internal hostname temporarily, just to confirm Postgres itself is healthy. If that works, it isolates the problem to internal networking specifically.
What this likely isn'tt
Not a Postgres crash, not data loss, not a config issue on your end. The timeout on the internal address with a healthy log is almost always Railway side networking.
Best next step
Open a Railway support ticket and explicitly mention the maintenance notification timestamp. Tell them the internal network did not reattach post maintenance. They can force a network rebind on their end that you cannot trigger yourself from the UI
2 months ago
Something I'd try is to go into your Postgres service settings and change the internal networking hostname to something arbitrary (pgdatabase for example) such that all your services access the Postgres instance from pgdatabase.railway.internal. Make sure to redeploy all associated services afterwards.