a month ago
I'm on the Hobby plan and experiencing recurring connection timeouts approximately every 2 hours, each lasting 10-16 minutes, that self-resolve. My project is deployed on us-west2 (Legacy) region.
The Railway deploy logs show no errors or crashes — the app is running fine. UptimeRobot confirms the timeouts are network-level (traceroute only reaches 2 hops before failing). This has been happening consistently for several days and persisted after upgrading from free to Hobby.
I'd like to be migrated off the legacy region to a stable non-legacy region. Please advise on the best path forward without losing my Postgres data.
Project: authentic-analysis
Services: web (FastAPI app) + Postgres database
3 Replies
a month ago
Your services are both running successfully with no application-level errors, so the recurring timeouts are consistent with legacy region infrastructure issues. You can self-migrate both services to Railway Metal by going to each service's Settings > Deploy > Regions and selecting a region tagged "Metal (New)", such as US West (California). For your Postgres service, the volume will be automatically migrated to the new region, and writes persist until the final remount, which causes roughly 30-45 seconds of downtime. We recommend creating a volume backup of your Postgres data before initiating the migration, and migrating both services to the same Metal region to avoid cross-region latency. Full migration details are in our Migrate to Railway Metal guide.
Status changed to Awaiting User Response Railway • about 1 month ago
Railway
Your services are both running successfully with no application-level errors, so the recurring timeouts are consistent with legacy region infrastructure issues. You can self-migrate both services to Railway Metal by going to each service's Settings > Deploy > Regions and selecting a region tagged "Metal (New)", such as US West (California). For your Postgres service, the volume will be automatically migrated to the new region, and writes persist until the final remount, which causes roughly 30-45 seconds of downtime. We recommend creating a [volume backup](https://docs.railway.com/volumes/backups) of your Postgres data before initiating the migration, and migrating both services to the same Metal region to avoid cross-region latency. Full migration details are in our [Migrate to Railway Metal guide](https://docs.railway.com/reference/migrate-to-railway-metal).
a month ago
I don't see a "Metal (new)" option. What can I do about this?
Status changed to Awaiting Railway Response Railway • about 1 month ago
Status changed to Open Railway • about 1 month ago
jvincini
I don't see a "Metal (new)" option. What can I do about this?
a month ago