a month ago
Hi Railway Team,
I am experiencing a prolonged internal networking and DNS resolution drop between my application container and my Postgres database, alongside a false "Crashed" banner in the dashboard UI. I suspect this is tied to the ongoing SSH/TCP proxy issues other users are currently reporting on the station forum.
1. The Internal DNS Drop
Starting at exactly 03:04:01 UTC, my Python backend completely lost its internal connection to the database. The private network mesh failed to resolve the Postgres host, taking down my background workers and causing cascading 500 Internal Server Errors on my live frontend endpoints.
Error traceback:
sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) could not translate host name "postgres.railway.internal" to address: Name or service not known
2. The Dashboard "Ghost Error" Contradiction
When I look at my Railway dashboard, the Postgres service displays a yellow warning box stating: "Deployment was removed because it's been crashed for too long," and the sidebar claims it crashed 2 weeks ago.
However, my Activity feed shows my application successfully deploying 9 hours ago, 19 hours ago, and yesterday. Since my app runs Alembic database migrations on every deploy, the database was definitively alive and healthy until the network drop at 03:04 UTC today. I suspect this is a UI ghost error, but it is prompting me to deploy a new Postgres image, which I cannot do for fear of wiping my production data.
3. Connection to Active Network Outages
I see active threads from other users reporting SSH connection failures with the "mintDevToken is only available in dev/staging" error. Since both external SSH proxying and my internal app rely on the same internal routing mesh to locate the database, it seems the DNS resolution layer for this cluster is failing.
Could you please investigate the internal .internal DNS routing for this project and help clear the false "Crashed" state on the Postgres UI so I can safely spin up my connections again without risking data loss?
1 Replies
a month ago
Your Postgres service has a volume attached (mounted at /var/lib/postgresql/data, state READY), so your data is safe across redeployments. The "Deployment was removed because it's been crashed for too long" message is not a UI ghost error; it means the Postgres deployment genuinely crashed and was removed after exhausting restart retries. Internal DNS for postgres.railway.internal cannot resolve because there is no running Postgres deployment to point to, which explains the cascading connection failures in your app. To bring it back, open the Postgres service, press Cmd/Ctrl+K, and select "Redeploy source image" to pull a fresh image while preserving your volume data.
Status changed to Awaiting User Response Railway • about 1 month ago
Status changed to Solved luvakashdear • about 1 month ago