13 days ago
Production service down 40+ minutes. Scale-to-0-then-1 did NOT clear the stuck lock.
Service: preleilao (ID: b0c01512-ea5f-4dfc-a0db-ef3962e859ff)
Project: protective-luck (ID: ee10c4c6-3756-4871-a3d7-8d02a4f8908c)
Environment: production (ID: a5678bce-2ea3-4574-982c-9f71be2dcefb)
Region: us-west2
Volume mounted at: /data
Deployment timeline:
- Original stuck deployment: 60f0ae60-ea95-401e-b602-4adb3d86d709 (stuck on CREATE_CONTAINER since 15:35:41Z)
- Scale-down deployment: 836358ea-e9a2-4da1-8a39-efd0847e5329 (15:54:08Z)
- Scale-up deployment: ae1d342d-ba9a-4375-8ad6-f82a4f8ef010 (15:54:12Z)
Current symptoms:
- All requests return 502 with x-railway-fallback:true
- Scale-to-0 completed but did NOT release volume lock
- New containers still cannot attach to /data
- Auto-deploy is disabled (no cascading redeploys)
Need: Server-side investigation and force-release of stuck container process holding /data volume lock. Not a redeploy retry — the lock is persisting even after complete shutdown.
This is NOT a code or config issue — the volume lock is physically held by infrastructure. Need forced cleanup.
1 Replies
Status changed to Awaiting Railway Response Railway • 13 days ago
12 days ago
Your read is right. A previous container did not shut down on our side, and it
is still holding the mount, which is why scaling back up did not release it and
why the replacement volume did not change the outcome. This is not caused by
anything in your project or your application code, so further redeploys will
not clear it. Both the original volume and the replacement you created on the
8th are healthy, and your data is intact on both. We are clearing the stuck
container from our side and will confirm here once you can redeploy.
Status changed to Awaiting User Response Railway • 12 days ago