A server hosting your Postgres database in production experienced a hardware failure yesterday at around 17:14 UTC, and the database was automatically migrated to a healthy server. That migration restarted Postgres, which would have caused all services depending on it to lose their database connections and go down until the migration completed (roughly 60 minutes). This was not initiated by anyone on our team - it was an automated response to a hardware event, and your services should have recovered on their own once the database came back online. All your production services are currently running normally.

Thank you for the explanation. I understand that hardware failures can happen, but I’m concerned that a failure on a single server hosting our production Postgres database caused our entire production environment to remain unavailable for roughly 60 minutes.

Since Railway is managing the infrastructure and database hosting, could you please clarify:

1. Is an outage of this duration considered normal or expected for a Railway-managed Postgres database after a hardware failure?
2. Why was there no automatic failover to a standby database that could keep our applications available?
3. Does our current Railway plan include any high-availability or redundancy protection for Postgres?
4. What architecture, configuration, or Railway service should we use to prevent a single database host failure from taking down all our production applications in the future?
5. Is there an SLA or documented recovery-time target for this type of incident?
6. Can you confirm whether the approximately 60-minute migration and recovery time was expected, or whether something delayed the recovery?

We are expecting significant growth over the next few months and plan to expand our customer base substantially. As Bumpy.fm becomes responsible for more customers and live events, an hour-long outage could have a serious operational and financial impact.

We therefore need to ensure that this type of incident cannot take down our entire platform again. Please provide a clear recommendation for the production architecture, failover mechanisms, redundancy, backups, recovery process, and Railway plan required to achieve the highest possible availability, including any necessary changes and their associated costs.

This is a question the Railway community is better placed to answer than support: people who have already worked this out on their own projects and can tell you what actually worked.

So we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who answers it, and threads like this usually get picked up quickly.

Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.

• Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
• Keep it private and close the thread - Nothing becomes public and the thread closes.