Railway resource limits (e.g., 24 GB RAM / 24 vCPU) apply strictly per replica, not as a shared global pool. In Sum mode, the dashboard aggregates total usage while displaying the individual replica's limit line, creating a false visual impression of a threshold breach. Playwright crashes are typically caused by load spikes hitting a single replica's isolated limit, triggering an Out-Of-Memory (OOM) termination. To troubleshoot, use Average mode for accurate monitoring, restrict Playwright parallel workers, or increase replica count.

1. The 24 applies to a replica. (https://railway.com/pricing)

24 GB/vCPU allocated to the service means it can use up to 24 GB/vCPU. However, the y-axis of the graph will only display the limit of a single replica (24 for your case). For the aggregate memory limit across all replicas, it's still 24 GB limits across each replicas, not a big 240 pool. And no, these configurations wouldn't cause process terminations. It's also possible that the terminations are caused by PID exhaustions.

Thats correct, its an Out-Of-Memory (OOM) termination, but the problem is observability on railway is poor. It does not reflects correct data

Railway says the max capacity is per resource, but their metrics graph do not really share reliable data

Railway as a platform seems less reliable to me, with all the recent outages and now this concern

Thanks buddy for the response, I appreciate!

The y-axis on the graph should be fixed OR REMOVED, its not really helpful in the current state, don't you think so?

In my case I'm executing playwright tests, and they are aborting abruptly (on each of the replica) during a session. The observed is "termination due to Out-Of-Memory (OOM)", when I checked memory usage of each replica, none of them crossed the limit. However, the combined usage did cross the threshold.

That's where all the confusion is stemming from, like if 24vCPU/GB is the max available resource for EACH replica, then how come it terminates, even when none of the replica never crossed the limit

Can you help me with "It's also possible that the terminations are caused by PID exhaustions.", --> like how do I find what PIDs are consuming how much of resource, I don't know where can I see this information, I tried SSHing into the replica, but its hell slow

Thanks buddy for the response, I appreciate!

The important part here is that the combined memory usage crossing 24 GB should not itself trigger an OOM if the replicas are isolated. I'd stop using the Sum graph to diagnose the termination and inspect the replica that actually died.

Since you're running Playwright, I'd check PID exhaustion as well as the cgroup OOM counter. Playwright/Chromium can create a surprising number of child processes, especially with parallel workers and repeated browser launches.

Inside one replica, try:

echo "pids current/limit:"
cat /sys/fs/cgroup/pids.current
cat /sys/fs/cgroup/pids.max

echo "memory events:"
cat /sys/fs/cgroup/memory.events

echo "top process counts:"
ps -e -o comm= | sort | uniq -c | sort -nr | head -20

memory.events is particularly useful because it should show whether the cgroup actually recorded an OOM:

oom
oom_kill

If oom_kill increments, then it really was memory pressure on that specific replica/cgroup, regardless of what the aggregated graph showed.

If memory looks comfortably below 24 GB but pids.current is approaching pids.max, then PID exhaustion becomes a much stronger explanation. Chromium is a good candidate here because each browser can spawn multiple renderer/GPU/utility processes.

I'd also log these values periodically from the test runner rather than checking manually over SSH. That should make it possible to correlate the exact moment Playwright dies with either:

• memory.current approaching memory.max
• an increment in memory.events
• pids.current approaching pids.max

For Playwright specifically, I'd also check whether every test/session is properly closing its browser/context/page. A slow process leak can look like an OOM problem even when the RAM graph doesn't show an obvious spike.

Something like:

await context.close();
await browser.close();

after each isolated session is worth verifying.

The key is to inspect the cgroup counters on an individual replica. The Railway aggregate graph can be confusing here, but memory.events and pids.current should tell you what the kernel/container actually enforced.