a month ago
To: support@railway.com (or via the in-app Help → Contact Support)
Hi Railway Support,
I have three deployments on my project that Railway's control plane marked REMOVED on June 25, 2026, but whose containers are still running and billing today — over three weeks later. I cannot terminate them through any API or dashboard path because every control-plane operation treats them as already deleted.
Project / service details:
-
Project ID: a21ae488-1b24-43b1-8c03-fcf344bb6094 (project name: gentle-recreation)
-
Service: aurum-bot-lite (service ID: 1bce66ee-f4a7-49a4-acc2-d9876af7fbe9)
-
Orphaned deployment IDs (all created 2026-06-25 ~19:14–19:15 UTC in a rapid deploy sequence, all status REMOVED):
a. 5b861fde-6710-49c0-bf3b-e301ab6f549b
b. 610be441-4477-492a-ba59-caa1b703aa70
c. d7e025e2-f4cf-4a41-8089-41c16cad8c86
Evidence they are still running:
- deploymentLogs for all three IDs returns live application output as recently as 2026-07-20 02:35 UTC (our scheduled jobs' log lines, continuously since June 25).
- Project metrics grouped by DEPLOYMENT_ID show these three consuming ~9.4 GB, ~8.4 GB, and ~5.5 GB of memory respectively (≈23 GB combined average) — they are the largest memory consumers in the project and appear in our billed usage.
Evidence the control plane cannot reach them:
- deploymentStop on these IDs returns the error: "Deployment iRVER_ERROR).
- deploymentRemove returns true but is a no-op — the containers keep running and logging afterward.
- deploymentCancel and restarts likewise have no effect on them.
- The deployments' status has been REMOVED the entire time, so/remove action for them either.
This looks like a control-plane/runner desync from the June 25 deploy burst: the deployment records were marked removed, but the kill signals never reached the containers, leaving them orphaned host-side with n
Requests:
- Please terminate these three containers host-side.
- Please review our usage/billing since 2026-06-25 for this service — roughly 23 GB of continuous memory over three-plus weeks is attributable to containers your platform recorded as removed, and I'd appreciate a credit for that orphaned usage.
- If possible, a brief note on what caused the desync, so we t trigger it.
Happy to provide trace IDs from the failed mutations or any additional logs you need.
Thank you,
Terrance Robinson
Account email: rterrance95@gmail.com
0 Replies