Your Pro plan supports up to 24 GB of memory per service, but your cgroupMemoryLimit showing 512 MB indicates you have a Replica Limit set on this service that caps it. Go to your service's Settings > Deploy > Replica Limits and either increase or remove the memory limit there - that is separate from the plan-level maximum and directly controls the cgroup constraint your app sees.

I do not see anything under the setting - Deploy that show replica limits

replica limits shows to be at 24GB and that is what it use to say in my api/health

The setting is in your service's Settings tab, under the "Deploy" section, labeled "Replica Limits" - you can see the docs reference here. If you don't see a value set there, it means no manual cap is in place, and the 512 MB cgroupMemoryLimit you're seeing is from Railway's vertical autoscaler, which dynamically adjusts the memory allocation based on your service's current usage and scales up automatically as demand increases.

mine is set to the full 24GB

A few things stand out here:

If Replica Limits is already set to 24GB, then the important part is that the runtime itself is still reporting:

cgroupMemoryLimit: 512MB

That means the container currently booted with a 512MB cgroup allocation, not just that Node is using 512MB.

A couple questions that would help narrow this down:

• Did this start after a redeploy/runtime update?
• Is this a Web Service, Background Worker, or something else?
• Are you seeing container restarts/OOM kills in the deploy logs?
• Does memory usage spike during API calls or is it stable?
• Are you using Node cluster/workers, streaming responses, or large payload buffering?

Also, Railway support mentioned vertical autoscaling, but in practice autoscaling usually reacts AFTER pressure increases. If the process gets killed or throttled before scale-up happens, API calls can start failing while the container still reports 512MB.

I would test these specifically:

1. Check actual cgroup limit inside the container:

cat /sys/fs/cgroup/memory.max

1. Check whether Node itself is capped:

node -e "console.log(require('v8').getHeapStatistics())"

1. Force Node heap higher temporarily:

NODE_OPTIONS=--max-old-space-size=4096

1. Watch deploy/runtime logs for:

• OOMKilled
• SIGKILL
• container restart loops
• memory pressure warnings

Another possibility is that Railway changed the initial allocation behavior recently and services now start at 512MB baseline unless sustained pressure triggers upscale. If that’s the case, API bursts could fail before autoscaling reacts.

The important clue is that your app was previously reporting ~2GB in health checks and now consistently reports 512MB despite unchanged Replica Limits. That suggests either:

• a platform/runtime allocation behavior change,
• autoscaler regression,
• or the service is no longer being classified the same way internally.