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