Since today (~June 23), every external request to several of my services takes

2–30+ seconds (TTFB), intermittently, and some requests fail with the Railway

"upstream error" page. The apps themselves are healthy — the latency is being

added between the public *.up.railway.app domain and the container.

This hits **multiple services across separate projects, all in the sfo

(us-west) region**, at the same time — which is why I think it's edge/region

infra, not my code.

Evidence the apps are fine and the edge is the bottleneck:

• Same /api/health endpoint, measured inside the container (hitting the

  Next.js server on localhost:$PORT): 1–15 ms, HTTP 200.

• DB round-trip on the private network (postgres.railway.internal):

  connect ~6–50 ms, SELECT 1 0–2 ms.

• The same endpoint over the public URL: 2–14 s TTFB, spiking to 30 s on

  full pages, and sometimes "upstream error".

• railway metrics on both the web services AND their Postgres: CPU `< 0.01

  vCPU`, memory ~2%, HTTP error rate 0% — everything idle. Requests succeed,

  just very slowly.

Already tried (no durable fix): redeployed/restarted the web services and

the Postgres services; confirmed the DB host is the internal one (not the

public proxy). Railway status page shows "UP".

Questions:

1. Is anyone else in the sfo / us-west region seeing edge latency or

   "upstream error" right now?

2. Is there a known edge/router/ingress degradation in that region?

3. What's the recommended mitigation — does changing a service's region help,

   or is this expected to clear on its own?

Example service (public): https://ads-platform-production-3f41.up.railway.app/api/health

Happy to share project/service IDs privately if a staff member can look.