Problem

I deploy a small Express app to one service with a single replica. After each new deploy, I expect the new deployment to take all traffic once it's healthy. Instead, requests alternate roughly 50/50 between the new deployment and the previous one for 30–40+ minutes, so visitors randomly get the old version. It always settles on the new version eventually; right now only the new one is answering. Has anyone seen this, or does someone on the Railway team know how to stop the old deployment from receiving traffic?

Setup

Service with root directory dashboard/, deploying from a GitHub branch, 1 replica

Custom domain, proxied through Cloudflare

Node / Express app with a /healthz endpoint

What I saw

Most recent case: the new deployment was commit 357dec0 and the previous one was 22ff767.

After the push, only 357dec0 answered for about 10 minutes.

From about 7:45 pm to 8:30 pm MT on Oct 25, 2026, requests alternated roughly 50/50 between 357dec0 and 22ff767.

On Oct 26 it was back to normal: 12 of 12 requests came from 357dec0.

My two previous deploys showed the same pattern.

I can tell which deployment answered because each build puts the first 8 characters of RAILWAY_GIT_COMMIT_SHA into its asset URLs (styles.css?v=). I add a random query string to every request, so no cache is serving an old copy:

for i in $(seq 1 12); do curl -s "https:///login?n=$RANDOM" | grep -o 'styles.css?v=[a-z0-9]*' | head -1; done | sort | uniq -c

During the window this printed a mix of v=357dec0e and v=22ff767….

What I've tried (none of it stopped the alternating)

The app handles SIGTERM: it stops accepting new connections, sends Connection: close, closes idle connections, and exits within 10 seconds.

I set the healthcheck path to /healthz, turned on Teardown in the service settings, and redeployed.

I checked the replica count (1) and the Networking settings; neither showed anything unusual.

What I don't know

The cause. My dashboard showed a banner about recovery from the Oct 21 incident, so it might be related, but that's a guess.

Whether Cloudflare (proxied DNS) is involved. I haven't tested with the proxy turned off.

What status the dashboard showed for the old deployment while the traffic was alternating.

Questions

Can the previous deployment's instance stay in routing after the new deployment is active? Is there a setting that controls this?

Could someone from Railway check whether my service still has a stale instance attached? I can share the project ID privately.

Is there anything else in my configuration I should change?