Hey sticky boy I think what you're facing with railway is as a result of undersea cable disruption causing the Philippines and Singapore cable segment to go offline earlier today.

And due to this there has been an increased latency and intermittent connectivity reported by some users in the Philippines when accessing services hosted in Singapore or further abroad. Similar slowdowns have been reported across major local ISPs.

So yeah you are right it is indeed a  regional networking problem affecting traffic from the Philippines, not a failure on Railway’s side.  I don't know if accessing other sites might have also been slightly slower than usual not just for you but maybe others around you, if yes that just confirms all I've just said. You could get someone close to try accessing the Railway dashboard from their own end to officially confirm everything. I'm not from the Philippines by the way, but I just suspected and did my research but I hope this helps

These are the posts confirming the cable disruption by the way:

UP Diliman Network Helpdesk (original advisory)

https://www.facebook.com/updilnet/posts/advisorywe-have-been-informed-that-one-of-the-undersea-cable-segments-between-ph/1565595048916050/

The cable disruption is real and it explains your dashboard access from Manila. But it doesn't explain your strongest piece of evidence, and I think there are two separate issues here.

Your uptime monitor ran from eu-west-nl and recorded 6.2s TTFB with DNS, TCP and TLS all under 10ms. Amsterdam → Singapore traffic doesn't route through the Philippines, so a PH–SG cable segment going down can't produce that. Something else is making that request slow.

The breakdown tells you what. Sub-10ms for DNS/TCP/TLS means the network path and connection setup are healthy — the latency is entirely in time-to-first-byte, which is your application thinking before it responds. That's not routing, that's the service itself.

Worth noting your two tests aren't comparable: the US test hit "a lightweight endpoint" at 44ms, while the monitor hits whatever path you configured it against. If those are different endpoints, you've compared a trivial handler against one that queries a database — and a 6.2s TTFB on a DB-backed route from a cold or contended connection pool is entirely ordinary. Point the US test at the same URL the monitor uses and see whether 44ms holds.

Things that produce slow TTFB with fast connection setup, in rough order of likelihood:

• A cold start. If the service scales to zero or had been idle, the first request after idle pays container start plus app boot. Intermittent slowness that disappears under steady traffic is the signature.
• Connection pool exhaustion. Requests queue waiting for a DB connection while the socket is already open — exactly fast-TLS, slow-TTFB.
• A slow query on that specific route, which only shows under certain data or after a migration.
• Resource ceiling. Check the Metrics tab for CPU pegged or memory near the limit during those windows; a throttled container responds slowly without failing.

So: the cable explains why you can't reach the dashboard from Manila, and that will resolve as repairs land. It doesn't explain the 6.2s from Amsterdam, and I'd treat that as a separate application-side issue that was probably present before Oct 2 and just got noticed during the outage. Check your Metrics and your deploy logs for that window — if TTFB was already elevated before 15:00 on the 2nd, that settles it.