All Discussions

Pinned Threads

+53

6 months ago

•

67 replies

+22
+38

Everything

Questions

Feedback

Bounties

Community

Sort by:

Status:


Help hahaAwaiting User Response

Hi Railway Support, Our Opero application is currently down in both Production and Test. During a deployment, our existing production service was stopped. Unfortunately, due to the ongoing Railway incident, we are now unable to restart the previous deployment or restore the service. We have already attempted to restart and roll back, but Railway blocks both actions. Current situation: - Production and Test are unavailable. - The previous production deployment needs to be restored. - No database migrations have been executed. - A fresh database backup is available. - Our Development environment is still working. Our priority is to restore the previously working production deployment as quickly as possible, without making any database changes. Could your team manually restart or restore our previous production deployment, or provide an alternative recovery method while deployments are blocked? Please also confirm whether the existing production data and volumes remain intact. This is affecting our live application, so we would appreciate urgent assistance. Thank you.

7 minutes ago

•

3 replies


Our project 73164943-3d20-44b7-9161-35088a33326a cannot start new deployments. Repeated attempts return “Deploys have been paused temporarily”. Is this entirely caused by incident QH8L8B3E, or is there also an account/project restriction? Please confirm what is needed to restore deployments and whether failed attempts must be triggered again afterward.

13 minutes ago

•

No replies yet


Hello Railway Support Team, I'm the founder of GOM Marketplace PH, and our production backend is currently hosted on Railway in the Southeast Asia region. I noticed that Railway is experiencing a major outage and that new deployments have been temporarily paused. Our dashboard is displaying "Limited Access – Deploys have been paused temporarily." I understand that your engineering team is actively working to resolve the incident. I'd like to ask a few questions: Is there an estimated time for full service restoration, particularly for deployments in Southeast Asia? Are existing production deployments expected to remain operational throughout the incident? Are there any known risks to running services, PostgreSQL databases, or existing API connections? Will deployments automatically resume once the issue is resolved, or will we need to manually redeploy? Our platform depends on Railway for backend operations, so even an approximate recovery window would help us plan accordingly. Thank you for your efforts in resolving this issue. I appreciate any updates you can provide. Best regards, GOM Marketplace PH

33 minutes ago

•

No replies yet


Subject: Deployments paused with “Limited Access” despite active Hobby plan Hello Railway Support, My Railway project airy-forgiveness has a web service connected to the GitHub repository rimilmandi/kherwar-calendar-final, branch main. My latest code commit is 8aaebc7 (Add 13 Santali month images to admin panel). The commit was successfully pushed to GitHub, but Railway continues to display: “Limited Access — Deploys have been paused temporarily.” The currently active deployment is several hours old, and the latest changes are not appearing on my website. My workspace is on the Hobby plan, and the Usage page shows $1.08 current usage against $5.00 included usage. Could you please check why deployments are paused and help restore deployment access? Thank you.

34 minutes ago

•

2 replies


All services cannot be viewed or accessed in the dashboard, nor can they be accessed through apis --- Builds are temporarily paused. We're investigating. View details

40 minutes ago

•

9 replies

+5

Hi! I’m on an active Hobby plan (usage $1.46 of $5, no limits reached). Since today (Oct 21) I can’t create any new project. Via the dashboard I get “You are creating projects too quickly. This workspace allows 1 project per 30 seconds”, even after waiting much longer. Via the API I get “Deploys have been paused temporarily”. Existing services in my projects keep running. Could you please check whether there is a flag on my account and lift it? Username: markflarens. Thanks!

41 minutes ago

•

1 reply


Issue with Deploying a Build?Awaiting User Response

Anyone else getting this message when you try to deploy? image.png

an hour ago

•

20 replies

+5

Hi Railway team, We run the Postgres HA template (Patroni + etcd + HAProxy) in project enigma-backend (2b3fa114-cb6e-4fce-be47-fc61adc5435b), production environment, region asia-southeast1-eqsg3a. On 21 October 2026 we had an unplanned failover that we traced to disk write stalls on the etcd volumes. Timeline (UTC): - 04:38:56–04:39:00 etcd-1 (etcd leader at the time) logged slow fdatasync took 4.200787039s, expected-duration 1s, plus leader failed to send out heartbeat on time; took too long, leader is overloaded likely from slow disk. - 04:38:58 etcd-2 started an election and became leader at term 54. - 04:39:00 Patroni on Postgres-3 (the primary) failed its lease keepalive with not a primary lessor, logged failed to update leader lock, and did Demoting self (immediate-nolock). Postgres shut down immediately. - 04:39:09 Postgres-3 promoted itself again. HAProxy had no primary for about 11 seconds, and clients saw server closed the connection unexpectedly. - 04:40:41–04:40:48 etcd-3 logged slow fdatasync took 7.653132093s. It was a follower, so there was no election. Volumes affected: - etcd-1-volume (13250b8b-688e-454e-ac41-ebbb5c2e1db0) - etcd-3-volume Two different volumes stalling within two minutes of each other suggests a storage or host problem in the region, not one bad disk. etcd-1 showed no other slow writes in the previous 7 days. Questions: 1. Was there a storage latency event in asia-southeast1-eqsg3a around 04:38–04:41 UTC on 21 October 2026? 2. Can the etcd volumes get storage with more consistent write latency, or be placed on separate hosts? 3. The template runs etcd with the default heartbeat (100 ms) and election timeout (1000 ms). Do you support or recommend setting ETCDHEARTBEATINTERVAL=500 and ETCDELECTIONTIMEOUT=5000 on the etcd services, so a short disk stall doesn't cause an etcd election and a Postgres failover? Would you consider changing the template defaults? 4. Is there a recommended way to restart the etcd members one at a time without causing a Patroni demotion? Thanks, Pranjal

an hour ago

•

1 reply


I am pro plan and it says Limited Access, Deploys have been paused temporarily.

an hour ago

•

2 replies


Please let me know when you have fixed the build issue mentioned above.

an hour ago

•

6 replies