a day ago
Title: Postgres container stopped silently for ~42 min, deployment still showed SUCCESS
Our Postgres service (Hobby plan) stopped responding on 2026-10-04 around 06:51 UTC.
The last log line was a routine checkpoint at 06:51:05; nothing was logged for 42 minutes.
Both the public TCP proxy and the private network (postgres.railway.internal) timed out.
At 07:33:45 the same deployment came back with "database system was not properly
shut down; automatic recovery in progress" and recovered fine.
No OOM, disk-full or "too many connections" messages, and our load is tiny.
The dashboard showed SUCCESS the whole time and the status page had no incident.
Questions:
- Is this a known host-level issue, and can a container freeze like this go undetected?
- What decides when a hung (not crashed) service gets restarted?
- Is there a health check or restart setting for database services we should use?
1 Replies
a day ago
The server running your Postgres service had an issue between about 06:55 and 07:40 UTC on 2026-10-04, which lines up with the window you saw. It affected that one server only, a notice about it went to your workspace, and the host has since recovered.
The restart policy only acts when the container actually stops or exits with an error. A process that is still running but not responding doesn't trigger it, and the deployment status stays SUCCESS while that is happening. The default policy is On Failure, and on Hobby you can switch it to Always in the service settings (restart policy).
Healthchecks won't catch a hang either. They only run when a deployment starts, before traffic switches to it, and are not used for continuous monitoring (healthchecks). To get alerted while a service is running, you can use an external monitor such as the Uptime Kuma template.
Status changed to Awaiting User Response Railway • 1 day ago