Production service stopped about 8 minutes into every deploy ("network configuration step took about 7.5 minutes"), while the same image runs fine on a sibling service

Setup: Hobby plan, Dockerfile builder, runtime V2, Python (Flask) web app. Happy to share project, service and deployment IDs privately with Railway staff.

What happens

Since Oct 31, 11:40 UTC, every deployment of one service (our production service) starts, serves traffic normally for about 8 minutes, and is then stopped by Railway: "SIGTERM received", "Stopping Container", deployment FAILED. With no earlier deployment to fall back on, the domain then returns 404 "Application not found". The dashboard's own diagnosis says the build and app startup were healthy and that "the network configuration step took about 7.5 minutes before the deployment was stopped."

The same commit and image run fine on a sibling service in the same project and environment (deployed by the same push) and on three other projects. The app does not crash; Railway stops it.

Timeline (UTC, Oct 31)

• 02:32 deploy: ran about 9 hours, fine (the last good one).
• 11:40 push (application code only): stopped at 11:50, about 8m41s after start.
• 12:13 manual redeploy: stopped after about 7m54s. Railway also emailed "Build failed" at 12:21, though the build had succeeded.
• 13:16 deploy (auto-created after we removed a stuck old deployment): about 7m58s.
• 14:56 deploy after adding PORT=8080: started 14:57:22, SIGTERM 15:05:15 (7m53s).
• 15:30 deploy after resetting the domains: started 15:30:34, SIGTERM 15:38:28 (7m54s).

Until the SIGTERM the logs show normal work: the app listening on 0.0.0.0:8080, background jobs completing, requests from Railway's edge (100.64.x.x) answered. The public domain answers with our sign-in page (HTTP 401, as expected) for the whole window.

What we tried (each followed by a fresh deploy; every one was stopped the same way)

1. Redeployed from the dashboard.
2. Removed a stuck old deployment.
3. Added the service variable PORT=8080 (the app already listened on 8080 by default).
4. Deleted the service's second Railway domain (explicit target port 8080) and replaced the main domain (also target port 8080) with a fresh Railway domain with no target port, renamed back to the same subdomain. It now matches the healthy sibling's single domain.

What we ruled out

• Code or image: the same commit runs fine on the sibling service in the same environment and on three other projects.
• Build timeout: redeploy builds finish in under a minute; the stop comes about 8 minutes after the app is up and serving.
• Port or binding: the app listens on 0.0.0.0:8080 (Dockerfile EXPOSE 8080; PORT now also set), and public traffic is served throughout the window.
• Health check: no healthcheck path is configured.
• Crash or restart policy: no crash. The process runs normally until Railway's SIGTERM, and the restart policy never fires.
• Volume: Ready, 2.5 GB of 5 GB used, mounted at /data, read fine by the app.
• Network flows: the private network flow logs look normal (DNS, outbound 443, inbound 8080).

Possible clues (things unique to this service)

• It is our oldest service (created July 2026) and exists in three environments: production (failing), staging (one deployment running since July 19) and demo (running since Oct 14).
• Production's volume is also attached to this service's instance in staging. A July "railway environment new --duplicate" left the same volume ID in both environments. The healthy sibling has its own volume and lives in one environment.
• Until today the service had two Railway domains, both with an explicit target port of 8080 (now replaced, as above).
• An unattached Postgres volume sits in the production environment.
• The dashboard has shown the October 21 incident banner all day ("A fix is out and we're monitoring it").

Please don't suggest deleting the volume or the staging environment. Because the volume ID is shared, deleting it from one environment once deleted it for all of them (July 2026).

Questions

1. What is the network configuration step waiting for on this service, and why does it time out at about 7.5 minutes only here?
2. Could the volume being referenced by two environments, or the service's age or region, block that step?
3. Can Railway reset this service's networking state from your side? If not, what is the safe way to move this volume to a fresh service, given that staging references it too?