10 days ago
Hi Railway team,
My Postgres database service crashed around April 10, 2026 and the deployment was removed on April 14, 2026 at 20:07 EDT with the message "Deployment was removed because it's been crashed for too long." The service then stayed offline until I manually redeployed it on August 11 — my app (seonostics.com) remained online the whole time, so every request failed with a DNS error for postgres.railway.internal.
Details:
- Project: SEO (27ef9b85-9632-4fe0-99ab-88dc322fe541), environment production
- Service: Postgres (043bb27d-d81c-4667-bdc0-dc0d2bc3fdaf), region US East
- Removed deployment: f57ac0ef, image ghcr.io/railwayapp-templates/postgres-ssl:18
Two questions:
- Root cause: Metrics show the service was healthy with trivial usage before the crash (~130 MB memory, near-zero CPU, 0.5 GB of a 5 GB volume), and redeploying the exact same image + volume on August 11 worked immediately with no issues. That points away from anything in my data or configuration. Was there a host/platform event around April 10 in US East that could have crashed the container? The crash logs are no longer retained on my side, so I can't diagnose it myself.
- Feedback: Removing a crashed database deployment and leaving it permanently offline — while dependent services stay up — is a silent failure mode. An automatic restart attempt after removal, or a louder escalation than a dashboard notification, would have prevented a four-month outage. Is auto-recovery for removed database deployments on the roadmap?
Thanks!
MO
1 Replies
10 days ago
No host maintenance events were found for your services in the available lookback window, and crash logs from April are beyond our retention period, so we can't confirm or rule out a specific platform-side cause for the initial crash. The "removed because it's been crashed for too long" behavior is expected: the default restart policy (On Failure, max 10 retries) exhausted its attempts, and once the deployment stayed in a crashed state without manual intervention it was removed. On your Hobby plan you can change the restart policy to "Always" with unlimited restarts in the service's settings, which keeps retrying indefinitely rather than stopping after 10 attempts - that would prevent a database from silently staying offline in this scenario.
Status changed to Awaiting User Response Railway • 10 days ago
3 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 3 days ago