3 months ago
I'm trying to serve a faster API for users, but I'm seeing unexpectedly high latency — even on a simple health endpoint.
I'm using Hono with Bun, and the route is extremely small:
app.get("/health", (c) => c.json({ status: "ok", service: "auth" }));The server is running with Bun like this:
export default {
fetch: app.fetch,
port: 3000,
hostname: '::',
keepAlive: 60_000,
idleTimeout: 70,
headersTimeout: 71,
}
However, the metrics I'm getting from curl are surprisingly slow:
$ curl -w "namelookup:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" -o /dev/null -s https://api.mestra.chat/health
namelookup:0.285863 connect:0.286653 tls:0.582073 ttfb:1.290903 total:1.291382
$ curl -w "namelookup:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" -o /dev/null -s https://api.mestra.chat/health
namelookup:0.003992 connect:0.004488 tls:0.304845 ttfb:0.674463 total:0.674929
Even for a static /health response, I’m getting ~600–1300ms total time, which feels too high.
I’m trying to understand whether the latency is coming from DNS, TLS handshake, Bun’s server, or something else in the network path.
Any suggestions on how to diagnose or optimize this would be greatly appreciated.
14 Replies
3 months ago
Hey there! We've found the following might help you get unblocked faster:
If you find the answer from one of these, please let us know by solving the thread!
3 months ago
cloudflare workers metrics
curl -w "namelookup:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" -o /dev/null -s https://cf.userdehghani.workers.dev/
namelookup:0.011472 connect:0.126053 tls:0.280923 ttfb:0.450037 total:0.455534
3 months ago
Hey,
This sounds like a routing issue. Can you give us some more diagnostic information and run a few commands for me?
The
x-railway-edgeheader from your http requesttracerouteto66.33.22.11tracerouteto66.33.22.1The deployment ID that is experiencing the issue
Status changed to Awaiting User Response Railway • 3 months ago
3 months ago
X-Railway-Edge: railway/us-east4-eqdc4a
deploymentId: f9801a8e-215b-4ec0-9ceb-74817e12266b
user traceroute:
traceroute 66.33.22.11
traceroute to 66.33.22.11 (66.33.22.11), 64 hops max, 40 byte packets
1 * * *
2 * * *
3 10.185.153.65 (10.185.153.65) 43.321 ms 25.092 ms 22.947 ms
4 10.155.147.5 (10.155.147.5) 32.242 ms 36.802 ms 33.353 ms
5 10.0.80.200 (10.0.80.200) 36.832 ms 31.734 ms 23.668 ms
6 10.0.81.97 (10.0.81.97) 37.518 ms 40.183 ms 28.105 ms
7 10.0.81.237 (10.0.81.237) 21.261 ms 27.156 ms 45.001 ms
8 10.0.81.244 (10.0.81.244) 68.896 ms 25.398 ms 24.306 ms
9 10.202.6.92 (10.202.6.92) 29.412 ms 28.082 ms 20.881 ms
10 10.21.41.12 (10.21.41.12) 32.285 ms 331.257 ms 26.356 ms
11 ix-et-4-0-5-0.tcore2.fnm-frankfurt.as6453.net (195.219.87.198) 107.573 ms 103.541 ms 99.063 ms
12 if-bundle-55-2.qcore2.fnm-frankfurt.as6453.net (195.219.87.57) 95.843 ms * 123.077 ms
13 if-bundle-66-2.qcore1.fr0-frankfurt.as6453.net (195.219.220.128) 188.492 ms * 110.022 ms
14 * 80.231.65.23 (80.231.65.23) 111.745 ms 100.767 ms
15 ae1.3101.ear7.ams1.neo.colt.net (171.75.9.165) 106.693 ms 110.732 ms 107.994 ms
16 lumen-techn.ear7.amsterdam1.level3.net (212.133.96.222) 96.475 ms 104.279 ms 100.039 ms
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
Status changed to Awaiting Railway Response Railway • 3 months ago
3 months ago
another unexpected things, simplest select and update query on database with internal connection take 31s long to response.
This happens time to time but it's really strange.
is there any cold start feature like serverless functions? if it is,i need to turn it off!
{
"message": "--> POST /auth/verify-otp \u001b[32m200\u001b[0m 31s",
"attributes": {
"level": "info"
},
"tags": {
"project": "392a5079-4981-4e79-b0c5-b09896e83b70",
"environment": "dae40a4f-a632-4b45-92d5-b6e6bb9d7e72",
"service": "df7efdeb-b2bf-4500-b19c-bb618634b843",
"deployment": "f9801a8e-215b-4ec0-9ceb-74817e12266b",
"replica": "effda741-8eea-49f3-8b90-4c300c9958dc"
},
"timestamp": "2025-12-04T10:10:11.639212275Z"
}
3 months ago
Same here
My service, n8n, is very very slow, like unusable
Same hereMy service, n8n, is very very slow, like unusable
3 months ago
Could you create your own thread and link it here please? 
Status changed to Awaiting User Response Railway • 3 months ago
userdeh
X-Railway-Edge: railway/us-east4-eqdc4adeploymentId: f9801a8e-215b-4ec0-9ceb-74817e12266buser traceroute:traceroute 66.33.22.11traceroute to 66.33.22.11 (66.33.22.11), 64 hops max, 40 byte packets1 * * *2 * * *3 10.185.153.65 (10.185.153.65) 43.321 ms 25.092 ms 22.947 ms4 10.155.147.5 (10.155.147.5) 32.242 ms 36.802 ms 33.353 ms5 10.0.80.200 (10.0.80.200) 36.832 ms 31.734 ms 23.668 ms6 10.0.81.97 (10.0.81.97) 37.518 ms 40.183 ms 28.105 ms7 10.0.81.237 (10.0.81.237) 21.261 ms 27.156 ms 45.001 ms8 10.0.81.244 (10.0.81.244) 68.896 ms 25.398 ms 24.306 ms9 10.202.6.92 (10.202.6.92) 29.412 ms 28.082 ms 20.881 ms10 10.21.41.12 (10.21.41.12) 32.285 ms 331.257 ms 26.356 ms11 ix-et-4-0-5-0.tcore2.fnm-frankfurt.as6453.net (195.219.87.198) 107.573 ms 103.541 ms 99.063 ms12 if-bundle-55-2.qcore2.fnm-frankfurt.as6453.net (195.219.87.57) 95.843 ms * 123.077 ms13 if-bundle-66-2.qcore1.fr0-frankfurt.as6453.net (195.219.220.128) 188.492 ms * 110.022 ms14 * 80.231.65.23 (80.231.65.23) 111.745 ms 100.767 ms15 ae1.3101.ear7.ams1.neo.colt.net (171.75.9.165) 106.693 ms 110.732 ms 107.994 ms16 lumen-techn.ear7.amsterdam1.level3.net (212.133.96.222) 96.475 ms 104.279 ms 100.039 ms17 * * *18 * * *19 * * *20 * * *21 * * *22 * * *23 * * *24 * * *25 * * *26 * * *27 * * *
3 months ago
Where are you connecting from?
Status changed to Awaiting Railway Response Railway • 3 months ago
3 months ago
Are you or any of your users able to follow the steps and attach the output here? https://docs.railway.com/reference/network-diagnostics
Status changed to Awaiting User Response Railway • 3 months ago
ray-chen
Are you or any of your users able to follow the steps and attach the output here? https://docs.railway.com/reference/network-diagnostics
3 months ago
users area
Railway Network Diagnostics
Generated : Saturday, Dec 6 2025 10:16:24 +0330
Endpoint : routing-info-production.up.railway.app
-------------------------------------------------------------------------------
Client IP Info
-------------------------------------------------------------------------------
{
"status": 429,
"error": {
"title": "Rate limit exceeded",
"message": "You've hit the daily limit for the unauthenticated API. Create an API access token by signing up to get 50k req/month."
}
}
-------------------------------------------------------------------------------
HTTP HEAD request
-------------------------------------------------------------------------------
Status: 200 OK
Status Code: 200
Protocol: HTTP/2.0
Response Headers:
Content-Type: text/html
Date: Sat, 06 Dec 2025 06:46:27 GMT
Server: railway-edge
X-Railway-Edge: railway/europe-west4-drams3a
X-Railway-Request-Id: O7_2IQ57TqiTu8Zrss7a6g
-------------------------------------------------------------------------------
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: 64431
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; 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: 146 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Dec 06 10:16:25 +0330 2025
;; 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: 9526
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;routing-info-production.up.railway.app. IN A
;; ANSWER SECTION:
routing-info-production.up.railway.app. 418 IN A 10.10.34.36
;; Query time: 12 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sat Dec 06 10:16:25 +0330 2025
;; MSG SIZE rcvd: 72
-------------------------------------------------------------------------------
Traceroute
-------------------------------------------------------------------------------
1 * *
2 81.91.153.241 (81.91.153.241) 9.407 ms 5.021 ms
3 172.27.18.17 (172.27.18.17) 47.239 ms 14.817 ms
4 172.27.16.193 (172.27.16.193) 10.398 ms 19.870 ms
5 172.21.2.70 (172.21.2.70) 21.920 ms 6.030 ms
6 172.21.2.153 (172.21.2.153) 62.851 ms 50.087 ms
7 172.20.21.105 (172.20.21.105) 6.301 ms 6.183 ms
8 172.20.40.38 (172.20.40.38) 6.283 ms 16.164 ms
9 * *
10 * *
11 10.202.6.198 (10.202.6.198) 11.945 ms 11.256 ms
12 10.21.212.10 (10.21.212.10) 13.990 ms 7.724 ms
13 213.144.184.62 (213.144.184.62) 97.190 ms 77.533 ms
14 89.221.34.189 (89.221.34.189) 87.876 ms 88.595 ms
15 ae1.3101.ear7.ams1.neo.colt.net (171.75.9.165) 84.206 ms 83.067 ms
16 lumen-techn.ear7.amsterdam1.level3.net (212.133.96.222) 93.452 ms 86.930 ms
17 66.33.22.232 (66.33.22.232) 87.790 ms 89.531 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=45 time=88.146 ms
64 bytes from 66.33.22.232: icmp_seq=1 ttl=45 time=88.461 ms
64 bytes from 66.33.22.232: icmp_seq=2 ttl=45 time=96.481 ms
64 bytes from 66.33.22.232: icmp_seq=3 ttl=45 time=86.555 ms
64 bytes from 66.33.22.232: icmp_seq=4 ttl=45 time=88.591 ms
64 bytes from 66.33.22.232: icmp_seq=5 ttl=45 time=86.634 ms
64 bytes from 66.33.22.232: icmp_seq=6 ttl=45 time=92.278 ms
64 bytes from 66.33.22.232: icmp_seq=7 ttl=45 time=85.838 ms
64 bytes from 66.33.22.232: icmp_seq=8 ttl=45 time=88.468 ms
64 bytes from 66.33.22.232: icmp_seq=9 ttl=45 time=107.308 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 = 85.838/90.876/107.308/6.243 ms
CompletedStatus changed to Awaiting Railway Response Railway • 3 months ago
3 months ago
metrics from the check-host.net
cloudflare workers: https://check-host.net/check-http?host=+https%3A%2F%2Fcf.userdehghani.workers.dev%2F
railway: https://check-host.net/check-http?host=https%3A%2F%2Fapi.mestra.chat%2Fhealth
3 months ago
I moved the services to EU West (Amsterdam),
which reduced latency from ~600–1300ms down to about ~350–600ms.
I also enabled Keep-Alive and applied several additional optimizations.
However, there’s still a significant gap before we can reach the performance levels that CF Workers provide by default.
3 months ago
Your traceroute looks normal. The latency is to be expected if connecting from the Middle East because they're currently routed to Amsterdam at the moment. Unfortunately we don't have a short-term solution for this - if performance is critical here, I would recommend sticking with CF workers.
Status changed to Awaiting User Response Railway • 3 months ago
Status changed to Solved userdeh • 3 months ago
Status changed to Solved userdeh • 3 months ago