a month ago
Project: b8de420c-dacd-4fb9-ba81-da127cb27e8e (platform)
Environment: 9c00f005-1c83-4656-ac75-dd76c92867e2 (production)
Since 2026-08-23T23:49Z, every deployment in this project hangs at INITIALIZING:
snapshotId null, events array empty, the stage list shows "Initialization: Not
started" — the job is created but never picked up. Last normal build:
2026-08-23T20:45Z (deployment b5846b77, SUCCESS).
What we ruled out ourselves:
-
GitHub App: healthy, repo access verified (Veritill/platform)
-
Branch: deploy AND main both hang (a1fcb277 = main, stuck)
-
Region: us-east (iad) AND us-west (sfo) both hang (6fba500e = sfo, stuck)
-
Trigger: GitHub webhook, API-triggered, AND
railway upCLI upload(3ac246e9) all hang identically
-
Plan/credit: upgraded Trial -> Hobby mid-incident, no change
-
Service state: deleted + recreated the web service, no change
The ONE thing that works: the automatic first deployment when a NEW service is
created. Two of those (e6b8c363 at 07:13Z, 6619d618 at 12:36Z) snapshotted
within seconds and built normally. Every subsequent deployment on any service
hangs. We are currently surviving on a freshly-created service ("webapp") as a
workaround.
Sample stuck deployment ids:
api: 9514fc5c, 0e06ed3e, c5417314, 027468aa
web: 5b71c129, 49ba72fb, a1fcb277, 6fba500e, 3ac246e9 (CLI upload)
1 Replies
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month ago
Your deploys aren't hanging, they're failing in the first seconds and the status never updates to show it. Both web and api have us-east set in their region config, and that isn't a Railway region name. It never has been. The deploy dies at the very first step trying to resolve it, before it can even snapshot your repo. That's why both branches, the API, and railway up all behave identically, and why a brand new service works: it starts with no region set.
Take us-east out of both services. Adding sfo next to it won't help, us-east itself has to come out. Our US East region is us-east4. In railway.json that's "multiRegionConfig": { "us-east": null, "us-east4": { "numReplicas": 1 } }, or set multiRegionConfig to null to use your workspace default. It's worth checking what wrote us-east in the first place, since a config-as-code commit will put it straight back.
The endless INITIALIZING with no events is on us. A deploy that can't resolve its region should say so plainly instead of sitting there silently.
Status changed to Awaiting User Response Railway • about 1 month ago
Status changed to Solved sam-a • about 1 month ago