Same thing from India this morning, against the Singapore region, in bursts. It is not your app being slow.

Run these two lines while it feels slow:

curl -s -o /dev/null -w "app tls=%{time_appconnect}s total=%{time_total}s\n" 'https://YOUR_APP_DOMAIN/health'

curl -s -o /dev/null -w "google tls=%{time_appconnect}s total=%{time_total}s\n" 'https://www.google.com'

Then open your service HTTP logs for that same minute.

What we saw, on a deployment that was otherwise idle:

• Google from the same laptop: about 0.2s
• railway.com and our Singapore app, from that laptop: often 10–20s, most of it in the TLS handshake
• The API container’s own log for the same request: about 50ms
• A static file the server logged at 1ms still took many seconds on the client

So the handler had already finished. The missing seconds were between Bangalore and the container, and they came and went. Rough windows today (IST): about 10:00–10:30, 10:50–11:10, and 11:20–11:30. By 11:43 IST the same checks were back under 0.3s.

Nothing in the app or the database setting fixes that path. When your two curls match this split, send Railway those times plus the HTTP log line. That is the evidence for the latency on the edge.

Does that check help ?

app tls=0.339198s total=0.413537s

noushadalims@Noushadalis-MacBook-Pro ~ % curl -s -o /dev/null -w "google tls=%{time_appconnect}s total=%{time_total}s\n" 'https://www.google.com'

google tls=0.152275s total=0.352581s

noushadalims@Noushadalis-MacBook-Pro ~ %

Try the following.

1. Use a custom domain. Indian ISPs sometimes deprioritize shared Railway domains (*.up.railway.app). Attach a custom domain and CNAME it to your service. This alone resolves most cases.
2. Disable serverless. If enabled, turn it off. It adds cold-start delays that compound network latency.
3. Change DNS to 1.1.1.1. Some Indian ISPs have poor DNS paths to Railway's edge. Cloudflare DNS improves initial routing.
4. Check which edge you hit. Run:

bash

curl -sI 'https://YOUR_APP_DOMAIN/health' | grep -i 'x-railway-edge'

If it returns gru1 (São Paulo) instead of sin1 (Singapore), your traffic is misrouted. This is a known anycast issue with Indian ISPs. Report this to Railway with the header and timings.

1. Escalate with evidence. Railway's sin1 edge has had intermittent TLS stalls (6–35s) in the handshake while TCP connects fine. When it happens, send Railway:

-The two curl outputs (app TLS vs Google TLS)

-The x-railway-edge header

-Exact IST timestamps

-Your HTTP logs showing the handler finished in ms

1. Alternative is, put Cloudflare in front. Configure Cloudflare as a proxy (orange cloud) on your custom domain. Indian traffic terminates TLS at Cloudflare's Mumbai POP (~55ms connect, ~131ms TTFB) instead of routing through São Paulo. Cloudflare's backbone carries it to Railway Singapore. This is a potential reliable long-term fix.

Summary:

Custom domain + disable serverless + 1.1.1.1 = immediate mitigation.

x-railway-edge check = diagnosis.

Railway ticket with evidence = potential routing fix.

Cloudflare proxy = permanent workaround.

The problem is edge-side, not your app or DB.

curl -s -o /dev/null -w "google tls=%{time_appconnect}s total=%{time_total}s\n" 'https://www.google.com'

google tls=0.000000s total=0.000010s

curl -s -o /dev/null -w "app tls=%{time_appconnect}s total=%{time_total}s\n" 'https://www.meeracreations.com/health

app tls=0.000000s total=0.000212s

Thanks for sharing your results, but those timings don’t look like real network measurements. total=0.000010s is 10 microseconds

• faster than a local loopback request, let alone a TLS handshake to Google or Railway. That means curl almost certainly didn’t make the network request you intended.

Two things stand out:

Your second command is missing the closing single quote after the URL:

... 'https://www.meeracreations.com/health

Without that ', the shell may have swallowed the rest of the line, so the command may not have executed as expected.

time_appconnect=0.000000 for both Google and your app means the TLS handshake time wasn’t measured at all. It doesn’t mean the handshake was instant.

Could you re-run the exact commands below while the issue is happening, and paste the full output?

curl -v -o /dev/null -w "connect=%{time_connect} appconnect=%{time_appconnect} starttransfer=%{time_starttransfer} total=%{time_total}\n" https://www.google.com

curl -v -o /dev/null -w "connect=%{time_connect} appconnect=%{time_appconnect} starttransfer=%{time_starttransfer} total=%{time_total}\n" https://www.meeracreations.com/health

Also please check which edge you’re hitting:

curl -sI https://www.meeracreations.com/health | grep -i 'x-railway-edge'

If you’re behind Cloudflare, also check:

curl -sI https://www.meeracreations.com/health | grep -i 'cf-ray|server'

The useful comparison is: Google should be fast (TLS under ~0.3s), while your app should show a large time_appconnect (6–35s) when the issue is active. If both are near zero, the test isn’t reaching the network or the problem isn’t occurring at that moment.