The diagnostics you've shared - sub-millisecond internal response with 6-16s TTFB from the public internet, idle CPU/memory, all services across both environments affected, both Railway and custom domains, no correlated deploys - are consistent with an infrastructure-level issue in the public ingress path rather than anything application-side. Could you reply with a specific domain and the approximate time window so we can trace the request path on our end?

Experiencing very slow responses.

https://api.catholicowned.com/health. I'm not exactly sure when this started, but the problem seems to be ongoing. I've tried a redeploy to see if that helps.

this is super slow, and has happened again less than a week ago! https://station.railway.com/questions/lag-on-specific-regions-170b5e8b

What’s most concerning is that this does not appear to be reflected on the status page, despite the issue having persisted for ~40 minutes and affecting the public endpoint consistently.

Yeah this is a big issue for me and my client and unfortunately (I love railway) is going to necessitate moving away if I can't guarantee it's not going to happen too many more times.

Same thing happening for me. Doesn't make any sense when Status page shows all green. Have been troubleshooting this for 30 minutes only to find that within the containers, everything is split second. Outside of containers, running 15 - 25 seconds for simple navigation of static pages

+1 — seeing the exact same thing.

• 20–30s TTFB from the public internet on every route, including a

  trivial /api/health endpoint (static JSON, no DB, no external calls).

• ~50–100ms from inside the container, so the app itself is fine.

• CPU and memory nearly idle; Postgres healthy; no deploy correlates.

• Region: US West. Started ~20:00 UTC on 2026-07-01, still ongoing.

  Intermittent 502s and occasional ERR_QUIC_PROTOCOL_ERROR.

Looks like edge/ingress or host-network degradation on Railway's side

same fix works, change your region in the scale section to US East, I was in US West like the last time when this was slow.

thank you for this! Implementing now

Experiencing the same Pro plan, no deploys since yesterday. Service (production) responds to a trivial dependency-free /health in 15–24s. Container metrics show idle CPU (~0.1 vCPU) and flat ~200MB memory; Postgres healthy. curl timing shows DNS/connect/TLS ~150ms total but TTFB 15.9s. Redeploy did not resolve. Requesting investigation of routing/placement for this service.

Confirmed that moving services from us-west2 to us-east4 resolved it while still entering via mia1; issue appears to be the mia1 -> us-west2 backhaul.

Thanks for the feedback. I moved also and we are back up running at previous speeds

mia1->us-west2 is degraded again as of ~22:15 UTC; identical requests to our services in us-east4 are 0.2s while us-west2 services are 5–25s through the same mia1 edge.

Hey!

We've since resolved this. Are you still running into it?

thank you! No we haven't been seeing it today.