9 days ago
Hobby plan. Project efficient-respect (ee721d1a-ad49-480a-9042-9211e598635d), Postgres service f7e4efa5-6cb8-40bf-a481-a52839e8d178, deployment de1fadaa, region US West, image ghcr.io/railwayapp-templates/postgres-ssl:latest.
The Postgres container looks wedged. It reports ACTIVE / Online but is not serving any connections.
What I'm seeing:
- Every client gets "timeout exceeded when trying to connect". My app service (n8n, same project, private networking) loops on pg-pool connection timeouts roughly every 20s.
-
- Railway's own Database tab on the Postgres service cannot connect either. It sits on "Attempting to connect to the database..." indefinitely, while "Deployment Online" and "Required Variables" both show green. That is what makes me think this is not my app or my credentials.
-
- The service emits no logs at all. Deploy logs show normal hourly checkpoints up to 2026-08-10 12:16 GMT+10, then nothing. In the project log stream for the last 15 minutes, every single line comes from my app service; Postgres produces zero output.
-
- Metrics: CPU flat at 0.0 vCPU, memory ~100 MB, public network traffic 0 B.
-
- The volume is not full - postgres-volume is using about 105 MB of 500 MB.
- What I have already tried:
-
- Deployment actions -> Restart on the Postgres service. It completed, but produced no new log output whatsoever, not even a startup line, and connections were still timing out ~25 minutes later.
- What I am asking for:
- Could you force-recycle the underlying instance? If possible please do it without re-pulling the :latest image tag. I am on Hobby so I have no backups or PITR available, and I would rather not risk the tag moving to a newer Postgres major version that then refuses to start against the existing data directory.
- The data itself appears intact (the volume is still there at ~105 MB) - it is just unreachable. Happy to provide anything else useful.
2 Replies
9 days ago
We can confirm the volume is attached and healthy (~124 MB used of 500 MB, state READY), so your data is intact on persistent storage. The Restart you tried reuses the existing container image without re-pulling it, which is likely why it had no effect on a wedged process. The next self-serve step is to open the command palette (Cmd+K / Ctrl+K) on the Postgres service and select "Redeploy source image", which re-pulls the image and creates a fresh container against the same volume. That re-pull will fetch whatever the ghcr.io/railwayapp-templates/postgres-ssl:latest tag currently resolves to, so if you want to control the exact version, you can first change the image tag in the service's source settings to a pinned digest or version tag before redeploying.
Status changed to Awaiting User Response Railway • 9 days ago
9 days ago
Resolved, and the cause was not what I assumed - posting the detail in case it helps someone who finds this later.
Postgres was fine. Using the service Console (SSH) I found the postgres process running normally with postmaster.pid reporting "ready", and psql answering over both the unix socket and 127.0.0.1:5432. pg_postmaster_start_time() showed the container had in fact restarted successfully when I hit Restart earlier - it had come back healthy. Connecting to postgres.railway.internal:5432 over private networking from inside the container also worked.
The actual problem was my app service: n8n was holding a Postgres connection pool that never recovered after the database became unreachable, so it kept timing out against a database that was by then perfectly healthy. Restarting the n8n service fixed it immediately.
One thing that genuinely misled me, and might be worth a look: after the Postgres restart the service produced no log output at all in the dashboard - no startup line, nothing - despite the process demonstrably running and serving queries. That absence of logs is what convinced me the container was wedged, and it is why I opened this thread. If log delivery for a restarted database service can silently stop like that, it is a confusing failure mode.
No need for the force-recycle. Thanks.
Status changed to Awaiting Railway Response Railway • 9 days ago
Status changed to Solved Railway • 9 days ago