We've looked into this from our side and haven't found anything on the Railway platform that explains what you're seeing, so working it out means digging into your specific setup.

That's exactly what the Railway community is good at, so we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who solves it, and threads like this usually get picked up quickly.

Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.

• Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
• Keep it private and close the thread - Nothing becomes public and the thread closes.

please look again. the code in that service deploy has not changed in more than 2 weeks. the only difference is today I was testing scaling it to more replicas during an ingest. something is stuck.

NOTE that this EXACT thing happened to me some time back, to which I got a similar response.. and eventually someone ELSE from railway looked at it and said yes, the problem is on the railway side.. and I was refunded some usage.

I suggest checking this again.

We still haven't found anything on the Railway side behind this, so the community is the best next step. The buttons below are still live: open the thread up as a public bounty after editing out anything sensitive, or keep it private and close it.

I just realized I was talking to a bot too. Can I get a support person to look at this?

Thanks mr-h. is this a known issue on railway? happened to me once before, they insisted it wasn't their fault until someone looked at it and said oops, it was our fault..

Also, I did check both metrics - the project metrics, and the service worker metrics. the service metrics still shows all the replicas, even though it scaled back to 1. after some time at least, but it's been several hours, the service metrics still shows replicas, and the project metrics still shows very high RAM usage for that worker..

no. and I restarted it, no effect, and then redeployed it.. also no effect. that service normally sits about 40mb when scaled to 1 and idle. but after testing 24 instead of 6 replicas during ingest, now it stuck at high ram..

I checked this at the container level rather than through the metrics dashboard.

There is one container running for the image worker right now, sitting at about 20 MB. That matches the single replica you're scaled to. Nothing else is running against that service.