Workspace/Project: slaygent

Project ID: a927f0e3-2744-4a6c-8b5e-d6a3d022bb16

Environment: production (ee34cf9e-3741-4d91-bb07-9559fc30bd2e)

Service: scraper (0f5e6825-9e2d-4578-a6b4-4f5a5cd52f6e)

My service is DOWN after hitting its spending cap due to a Railway platform issue, not actual usage.

The service is configured for 2 replicas, yet Railway is running and billing 153 container instances across deployments marked REMOVED.

Evidence (via GraphQL API):

1. serviceInstance.numReplicas = 2.

2. MEMORY_USAGE_GB grouped by DEPLOYMENT_INSTANCE_ID returns 153 active instances consuming ~54 GB continuously. Total CPU is only ~0.3 vCPU, indicating these containers are idle. Usage has remained ~57–68 GB for the past week regardless of traffic.

3. MEMORY_USAGE_GB grouped by DEPLOYMENT_ID shows most usage comes from removed deployments:

   • 07abdc3c-e550-494b-97e8-f46c175ee16f (REMOVED): ~120 instances, 42.4 GB

   • 18d827c0-898a-4d53-906a-ab9de850725f (REMOVED): ~31 instances, 10.9 GB

The only active deployment, 6942973e-e813-469c-9139-d6e15e6fbe66, uses 0.13 GB across 2 instances as expected.

1. deploymentStop returns "Deployment is not stoppable" for the orphaned deployments, so I cannot remove them myself.

This indicates deployments reported as REMOVED are still running and being billed. The dashboard shows 2 replicas, but the runtime/billing systems disagree.

Requests:

1. Force-terminate all orphaned instances from removed deployments (especially 07abdc3c and 18d827c0).
2. Refund/credit charges from these zombie containers since 2026-06-13 (~54 GB continuously billed).
3. Reset/lift the spending cap so production can recover.

Thanks.