We're aware of these transient build queue issues and are actively working on improvements.

"The diagnosis confirms it's a platform issue (3 consecutive deployment failures at container creation stage). My Postgres service is stuck with broken private networking - the internal hostname postgres.railway.internal is unreachable from my app service. I need a human to manually fix the DNS binding for my Postgres service. Project: poetic-nourishment, environment: production."

Hi — you're right that this is a platform-side issue, and the misleading part is the symptom: today's US West networking disruption left some services unable to route over private networking (postgres.railway.internal), even though the database itself is up and your data is safe.

If your Postgres container is still running, you can restore connectivity right now by switching your app from the internal URL to the public one:

1. Open your Postgres service → Variables and copy the value of DATABASE_PUBLIC_URL (it looks like postgresql://postgres:...@<host>.proxy.rlwy.net:<port>/railway).
2. Open your app service → Variables, edit DATABASE_URL, and paste that public URL.
3. Save — the service redeploys automatically and should connect.

This routes through the TCP proxy instead of the private network. It incurs a small egress cost (fractions of a cent), and you can switch back to the internal URL once private networking is confirmed fully restored in the region.

If your Postgres container itself won't start (deploys failing at "Create container"), that's the separate half of this issue and is being worked on our side — your volume stays intact in the meantime. Let me know which case you're in and I'll keep you posted.