a month ago
Hi everyone im deploying a service in SIngapore Region and accessing from Indonesia (Jakarta)
Why the response time is so slow? it took 0.9s to do healthcheck endpoint to deployed railway service while ususally SG and Jakarta ping is only around 15-20ms
curl -s -o /dev/null 'https://my-service.com/health' \
-w 'total=%{time_total}s ttfb=%{time_starttransfer}s connect=%{time_connect}s tls=%{time_appconnect}s\n'
total=0.936442s ttfb=0.936162s connect=0.204608s tls=0.408565s
3 Replies
Status changed to Awaiting Railway Response Railway • 29 days ago
a month ago
Hey! This sounds like a routing issue. Could you follow the steps in https://docs.railway.com/networking/troubleshooting/network-diagnostics and send the report here?
Also, please run this curl and share the X-Railway-Edge header value so we can confirm which edge your requests are hitting:
curl -sI 'https://my-service.com/health' | grep -i X-Railway-Edge
Your ~205ms TCP connect time from Jakarta to Singapore is much higher than the expected ~15-20ms, which suggests your requests may be routing through a distant edge rather than the Singapore one. The diagnostics report will help us confirm and investigate further.
Status changed to Awaiting User Response Railway • 28 days ago
ray-chen
Hey! This sounds like a routing issue. Could you follow the steps in <https://docs.railway.com/networking/troubleshooting/network-diagnostics> and send the report here? Also, please run this curl and share the `X-Railway-Edge` header value so we can confirm which edge your requests are hitting: curl -sI 'https://my-service.com/health' | grep -i X-Railway-Edge Your ~205ms TCP connect time from Jakarta to Singapore is much higher than the expected ~15-20ms, which suggests your requests may be routing through a distant edge rather than the Singapore one. The diagnostics report will help us confirm and investigate further.
a month ago
It is way so much better now the curl take this much, is this the number I can expect?
total=0.079301s ttfb=0.079199s connect=0.021884s tls=0.055717s
this is the edge request i am hitting from curl: x-railway-edge: railway/asia-southeast1-eqsg3a
and this is the network diagnostic i got
Railway Network Diagnostics
Generated : Wednesday, May 20 2026 10:45:31 WIB
Endpoint : routing-info-production.up.railway.app
-------------------------------------------------------------------------------
Client IP Info
-------------------------------------------------------------------------------
{
"ip": "",
"hostname": "host-158.140.191-99.myrepublic.co.id",
"city": "Jakarta",
"region": "Jakarta",
"country": "ID",
"loc": "",
"org": "AS63859 PT. Eka Mas Republik",
"postal": "12850",
"timezone": "Asia/Jakarta",
"readme": "https://ipinfo.io/missingauth"
}
-------------------------------------------------------------------------------
HTTP HEAD request
-------------------------------------------------------------------------------
Status: 200 OK
Status Code: 200
Protocol: HTTP/2.0
Response Headers:
X-Railway-Edge: railway/asia-southeast1-eqsg3a
X-Railway-Request-Id: HD-zQm0uSreWdtNKJH0Vcg
Content-Type: text/html
Date: Wed, 20 May 2026 03:45:32 GMT
Server: railway-edge
-------------------------------------------------------------------------------
DNS lookup (using system DNS)
-------------------------------------------------------------------------------
; <<>> DiG 9.10.6 <<>> routing-info-production.up.railway.app
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34322
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;routing-info-production.up.railway.app. IN A
;; ANSWER SECTION:
routing-info-production.up.railway.app. 600 IN A 66.33.22.232
;; Query time: 4 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed May 20 10:45:32 WIB 2026
;; MSG SIZE rcvd: 83
-------------------------------------------------------------------------------
DNS lookup (using Cloudflare)
-------------------------------------------------------------------------------
; <<>> DiG 9.10.6 <<>> @1.1.1.1 routing-info-production.up.railway.app
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57569
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;routing-info-production.up.railway.app. IN A
;; ANSWER SECTION:
routing-info-production.up.railway.app. 60 IN A 66.33.22.232
;; Query time: 21 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed May 20 10:45:32 WIB 2026
;; MSG SIZE rcvd: 83
-------------------------------------------------------------------------------
Traceroute
-------------------------------------------------------------------------------
1 192.168.1.1 (192.168.1.1) 3.880 ms 2.551 ms
2 * 10.15.128.1 (10.15.128.1) 7.744 ms
3 172.16.18.149 (172.16.18.149) 5.267 ms 12.854 ms
4 * *
5 172.17.2.69 (172.17.2.69) 6.932 ms 6.556 ms
6 * *
7 * *
8 400940.sgw.equinix.com (27.111.231.33) 23.496 ms 18.943 ms
9 66.33.22.232 (66.33.22.232) 18.796 ms 19.263 ms
-------------------------------------------------------------------------------
Ping (n=10)
-------------------------------------------------------------------------------
PING routing-info-production.up.railway.app (66.33.22.232): 56 data bytes
64 bytes from 66.33.22.232: icmp_seq=0 ttl=54 time=18.276 ms
64 bytes from 66.33.22.232: icmp_seq=1 ttl=54 time=22.128 ms
64 bytes from 66.33.22.232: icmp_seq=2 ttl=54 time=19.172 ms
64 bytes from 66.33.22.232: icmp_seq=3 ttl=54 time=17.677 ms
64 bytes from 66.33.22.232: icmp_seq=4 ttl=54 time=17.678 ms
64 bytes from 66.33.22.232: icmp_seq=5 ttl=54 time=18.437 ms
64 bytes from 66.33.22.232: icmp_seq=6 ttl=54 time=17.602 ms
64 bytes from 66.33.22.232: icmp_seq=7 ttl=54 time=17.421 ms
64 bytes from 66.33.22.232: icmp_seq=8 ttl=54 time=17.658 ms
64 bytes from 66.33.22.232: icmp_seq=9 ttl=54 time=21.702 ms
--- routing-info-production.up.railway.app ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 17.421/18.775/22.128/1.649 ms
CompletedAttachments
Status changed to Awaiting Railway Response Railway • 27 days ago
25 days ago
Hey! Those numbers look great — that's exactly what you'd expect for an HTTPS request from Jakarta to Singapore.
Your ping shows ~18ms round-trip time, but an HTTPS request requires multiple round trips:
- TCP handshake — 1 round trip (~22ms, matches your
connecttime) - TLS handshake — 1-2 round trips (~34ms additional)
- HTTP request/response — 1 round trip + server processing
So the theoretical minimum is around 60ms, and your 79ms total is right in that healthy range.
As for the initial ~936ms — your connect time alone was 205ms, which is way too high for Jakarta↔Singapore. One possibility is that your traffic was being routed through a distant edge instead of the Singapore one, which can happen when ISP routing temporarily picks a suboptimal path to our anycast network. That would be transient and explain why it resolved on its own. Your diagnostics now confirm you're hitting the correct Singapore edge (asia-southeast1-eqsg3a).
If you see it happen again, grab the X-Railway-Edge header right away — that'll tell us which edge you're hitting and help us narrow down the cause.
Status changed to Awaiting User Response Railway • 25 days ago
18 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 18 days ago