Edge router returns 502 x-railway-fallback: true on healthy service — all ingress dropped, container healthy
Anonymous
PROOP

a month ago

Hi Railway,

platform_api in our pre-staging env has been unreachable via the public edge for 1+ hour. Every request returns 502 x-railway-fallback: true, but

the container is healthy — uvicorn bound to [::]:8000, deploy SUCCESS, outbound HTTP works. Zero ingress ever reaches it.

IDs

- Project: 2cb0b7c3-f5dc-4594-a2b0-05a32fe5ba65 (courageous-creativity)

- Env (pre-staging): 81c47819-783f-44fb-8a9a-fdf0400b236f

- Current service: cae4d821-c9b1-401b-87c8-2a86e2770f96, us-west1

- Public domain: platformapi-pre-staging-88dd.up.railway.app (target port 8000)

- Latest SUCCESS deploy: 7f74d1ce-f318-43f1-a902-4573ccfdb485 @ 2026-04-20T18:12:40Z

- Original service (deleted during recovery): a8f0f7af-df00-4b79-a1cf-02c7c4e9b153, was us-west2

Request IDs for tracing: f9ylfoIDS6aLJJ0umrpb1w, 0yqBo2kPSp2_iW4cipRofQ, hYoxz0l-TeKJZDhIV7rehQ, mv_f-S0lSWyQUvzV-8Y8hA.

App logs (healthy): Started server process [1] → Application startup complete. → Uvicorn running on http://[::]:8000, then successful outbound calls

to Twilio, ElevenLabs, Cartesia, OpenRouter. Egress works, ingress never arrives.

Recovery attempts (all failed, 502 persists after each):

1. deploymentRestart

2. deploymentRedeploy ×3

3. serviceDomainDelete + serviceDomainCreate (new URL, still 502)

4. Full serviceDelete + serviceCreate with 67 env vars preserved (new service ID, new URL, still 502)

5. Dockerfile BuildKit cache-mount IDs updated to new service ID, pushed as 160bc3d3 — cold build succeeded

6. Region us-west2 → us-west1 (Railway banner: "The deployment configuration was automatically modified to ignore deprecated regions")

7. serviceInstanceRedeploy — SUCCESS, still 502

Observations

- The us-west2 deprecation banner suggests that rollover likely initiated the wedge on the original service.

- Other pre-staging services in this project (FlowForge-Frontend, Tool_Hub, voice_gateway) route fine — no x-railway-fallback. Scoped to

platform_api's edge entry.

- Upstream routing appears stuck: every request short-circuits to the fallback before reaching the container. Held across full service recreation

with new ID, new domain, new region — rules out local config.

Ask: please inspect edge/upstream state for cae4d821-c9b1-401b-87c8-2a86e2770f96 in env 81c47819-783f-44fb-8a9a-fdf0400b236f and force

re-registration, or tell us the config step we're missing. Blocking login on pre-staging. Happy to keep the current deploy untouched while you

investigate.

Thanks,

Abdul Rasheed Esa

$20 Bounty

1 Replies

Status changed to Awaiting Railway Response Railway about 1 month ago


Railway
BOT

a month ago

This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.

Status changed to Open Railway about 1 month ago


I recommend you set PORT to 8000 in your Railway Service Variables. Incoming requests might be routed to the port defined by the PORT environment variable, which Railway injects automatically (most likely it isn't 8000).


Welcome!

Sign in to your Railway account to join the conversation.

Loading...