This does not look like a Railway deployment/container restart. Exit code -11 is SIGSEGV; a cgroup OOM kill is normally SIGKILL / exit 137. If PID 1 (prefect worker start ...) stays alive and only the spawned flow subprocess dies, Railway will not necessarily show a deployment restart because the container itself did not exit.

For the Railway-specific parts:

1. I would not expect a separate Railway platform event for a non-PID-1 child process segfaulting inside a still-running container. Railway exposes deployment logs plus service CPU/memory/disk/network metrics, but not per-child-process crash records. If this were an OOM/resource-limit issue, check Railway Metrics and the container cgroup counters.

2. You can check the effective memory limit and OOM counters from inside the running container:

cat /sys/fs/cgroup/memory.max 2>/dev/null
cat /sys/fs/cgroup/memory.current 2>/dev/null
cat /sys/fs/cgroup/memory.peak 2>/dev/null
cat /sys/fs/cgroup/memory.events 2>/dev/null

On cgroup v2, memory.events is the important one. If oom / oom_kill does not increment when the Prefect child dies, this was not a kernel cgroup OOM kill.

You can also check Railway’s memory metrics with:

railway metrics --service prefect-worker --memory --since 6h --json

railway metrics --service prefect-ml-worker --memory --since 6h --json

Railway’s documented per-replica limits are 8 GB on Hobby and 24 GB on Pro, unless you configured a lower Replica Limit in Service Settings → Deploy → Replica Limits.

For core dumps, I would not rely on host-level core capture on Railway. You can try enabling core files in the container, but /proc/sys/kernel/core_pattern is often host-controlled in managed runtimes. A more reliable first step for Python native crashes is:

export PYTHONFAULTHANDLER=1

export PYTHONMALLOC=debug

and then reproduce with import tracing:

python -X faulthandler -v -c 'import grpc, cryptography, google.protobuf, mlflow, opentelemetry'

Given your timing, I would test this as a native-extension/import-time crash rather than a Railway kill. Temporarily reduce the worker to one child / one flow at a time. If serial execution stops the crashes, that strongly supports the concurrent native dependency init theory.

I would also pin-test the likely native packages one at a time, especially grpcio and protobuf:

grpcio==1.76.x

protobuf<6

and test a newer base image such as python:3.11-bookworm or python:3.12-slim-bookworm against the exact same app. python:3.11.8-slim-bookworm is old enough that I would verify on a current patch image before spending much more time debugging Railway itself.

Short version: Railway is probably not killing these subprocesses. Confirm with memory.events; if oom_kill is unchanged and the parent container/deployment remains alive, treat this as a segfault in a native Python dependency during concurrent child startup.

If this answer helps solve it, please mark it as the solution so others can find it too.