16 days ago
Hi, team-
A support agent confirmed there that sfo and us-west are the same region, my volume is correctly colocated there, and advised against changing regions. That held for a while — deploys were going through cleanly.
Today the same problem came back. Deployment d1cd4540-d3cb-4bb6-bd1a-f53ac3c007e6 (region sfo) — the exact same deployment ID from before — is again showing as SUCCESS/active even though it's been dead since yesterday (its logs stop cold on 2026-08-04). New deploy attempts got stuck behind it, with this failure message:
"This deployment failed because the container creation step hung indefinitely and was eventually stopped, not because of a code or config problem. The build and image push both completed successfully in seconds, but CREATE_CONTAINER stayed stuck in a pending state with no application logs before being manually stopped."
It self-resolved after about 25 minutes with no successful action on my end (redeploys and restarts all failed while it was down).
For context on frequency: this is the second time this specific deployment has caused an outage — roughly 2 hours on 2026-08-04, and now ~25 minutes today (2026-08-05, approximately 15:47–16:13 UTC).
d1cd4540-d3cb-4bb6-bd1a-f53ac3c007e6 is still showing as an active/not-removed deployment right now, even though it's been dead for over a day. Could someone check why that specific record isn't clearing, since this looks like it'll keep causing intermittent outages until it's actually gone? Service ID is b4fe46e2-c94f-41bf-8863-8c92ae4cab11.
Thank you!
Kevin
5 Replies
Status changed to Awaiting Railway Response Railway • 16 days ago
16 days ago
We confirmed that deployment d1cd4540 has a container stuck in a state our normal cleanup process could not resolve, which is what caused the intermittent deploy failures you saw. We've cleared the stuck state, so new deployments should proceed without hitting this again.
Status changed to Awaiting User Response Railway • 16 days ago
chandrika
We confirmed that deployment d1cd4540 has a container stuck in a state our normal cleanup process could not resolve, which is what caused the intermittent deploy failures you saw. We've cleared the stuck state, so new deployments should proceed without hitting this again.
16 days ago
Hi, Chandrika-
Thank you for quick response! Here's the breakdown from my agent:
Update with more data since my last message.
I ran two more test deploys after your fix:
Test 1: succeeded cleanly, through CREATE_CONTAINER in about 15 seconds.
Test 2: stuck in CREATE_CONTAINER/CREATED for about 25 minutes before failing on its own. Deployment ID e59a43d5-8518-43be-8ed2-c4283c288ffc.
Test 3: stuck in the identical state for about 14 minutes before failing. Deployment ID 2536ef2a (full ID available if useful).
So 2 of 3 test deploys after your fix hit the same failure mode. This looks intermittent, not resolved.
Separately, and more concerning: the deployment that had been running successfully since Test 1 (e1795fa4-f806-49e0-8245-2a44e14ec45b) appears to have restarted on its own around 20:00 UTC and did not come back — no log activity for about 13 minutes afterward, despite Railway's dashboard continuing to show it as "RUNNING." I had to manually intervene to restore service. So the impact isn't limited to failed new deploys — an already-running, previously-healthy deployment silently going dark is a separate and more serious symptom.
Service ID: b4fe46e2-c94f-41bf-8863-8c92ae4cab11
Status changed to Awaiting Railway Response Railway • 16 days ago
k6spaceman
Hi, Chandrika- Thank you for quick response! Here's the breakdown from my agent: Update with more data since my last message. I ran two more test deploys after your fix: Test 1: succeeded cleanly, through CREATE_CONTAINER in about 15 seconds. Test 2: stuck in CREATE_CONTAINER/CREATED for about 25 minutes before failing on its own. Deployment ID e59a43d5-8518-43be-8ed2-c4283c288ffc. Test 3: stuck in the identical state for about 14 minutes before failing. Deployment ID 2536ef2a (full ID available if useful). So 2 of 3 test deploys after your fix hit the same failure mode. This looks intermittent, not resolved. Separately, and more concerning: the deployment that had been running successfully since Test 1 (e1795fa4-f806-49e0-8245-2a44e14ec45b) appears to have restarted on its own around 20:00 UTC and did not come back — no log activity for about 13 minutes afterward, despite Railway's dashboard continuing to show it as "RUNNING." I had to manually intervene to restore service. So the impact isn't limited to failed new deploys — an already-running, previously-healthy deployment silently going dark is a separate and more serious symptom. Service ID: b4fe46e2-c94f-41bf-8863-8c92ae4cab11
16 days ago
Hi, Chandrika-
More info from the agent in case it's helpful, thank you!
Kevin
Deployment IDs and statuses (service b4fe46e2-c94f-41bf-8863-8c92ae4cab11, environment 649f1546-576c-4227-b15f-7e5a44c7a4f0, region sfo):
2536ef2a-96cb-4e0d-8a3c-fa191f8ff695 — FAILED, started 2026-08-05T19:56:32Z
37ff2a2f-e4bb-4ad2-9cfd-a2f93b888d90 — FAILED, started 2026-08-05T23:04:42Z
8782cd61-2c57-4899-b31e-3033a0c29815 — FAILED, started 2026-08-05T23:20:31Z
9a4b6957-d2eb-4996-b32c-97ccdb2266d3 — FAILED, started 2026-08-05T23:24:02Z
af617c57-5958-4f9e-ab09-cd826ad4c6ca — stuck in DEPLOYING since 2026-08-05T23:35:37Z, still unresolved 18+ minutes later, hasn't flipped to SUCCESS or FAILED
489236f3-9447-4221-ad9a-0aadc7292442 — QUEUED, blocked behind af617c57, can't even start
Currently-running instance is deployment e1795fa4-f806-49e0-8245-2a44e14ec45b — still healthy, logging normally. So the running service is fine, this is purely new deploys not going through, either failing outright or hanging in a non-terminal DEPLOYING state.
Pattern looks similar to the earlier stuck-container issue you resolved on d1cd4540 — could you check af617c57 specifically?
15 days ago
That's fixed. The stuck record for d1cd4540 is cleared, so your next deploy should go through normally instead of hanging in CREATE_CONTAINER.
That deployment's container got into a state our tooling couldn't stop, and since our records still showed it as active, every new deploy tried to shut it down first, waited about eight minutes, then gave up and rolled back. That's what af617c57 and the rest were hitting. Nothing to do with your code or config.
It also explains the part you flagged separately. Each failed deploy was stopping your healthy deployment as part of the normal swap, and it only came back when the rollback ran. That's the dead air around 20:00 UTC while the dashboard still said RUNNING. Same cause, not a second issue.
The d1cd4540 entry itself will clear on your next successful deploy.
Status changed to Awaiting User Response Railway • 15 days ago
sam-a
That's fixed. The stuck record for d1cd4540 is cleared, so your next deploy should go through normally instead of hanging in CREATE_CONTAINER. That deployment's container got into a state our tooling couldn't stop, and since our records still showed it as active, every new deploy tried to shut it down first, waited about eight minutes, then gave up and rolled back. That's what af617c57 and the rest were hitting. Nothing to do with your code or config. It also explains the part you flagged separately. Each failed deploy was stopping your healthy deployment as part of the normal swap, and it only came back when the rollback ran. That's the dead air around 20:00 UTC while the dashboard still said RUNNING. Same cause, not a second issue. The d1cd4540 entry itself will clear on your next successful deploy.
15 days ago
Thanks so much, team! Two deploys this morning, so I think we're probably good to go :)
Status changed to Awaiting Railway Response Railway • 15 days ago
Status changed to Solved k6spaceman • 15 days ago