seeing unexpectedly high latency!

6 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.

Solved

14 Replies

Railway
BOT

6 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!


6 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


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-edge header from your http request
  • traceroute to 66.33.22.11
  • traceroute to 66.33.22.1
  • The deployment ID that is experiencing the issue

Status changed to Awaiting User Response Railway 6 months ago


6 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 6 months ago


6 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"
}

Anonymous
PRO

6 months ago

Same here

My service, n8n, is very very slow, like unusable


Same here My service, n8n, is very very slow, like unusable

6 months ago

Could you create your own thread and link it here please? 🙏


Status changed to Awaiting User Response Railway 6 months ago


userdeh

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 * * *`

6 months ago

Where are you connecting from?


ray-chen

Where are you connecting from?

6 months ago

our users mostly from Middle East


Status changed to Awaiting Railway Response Railway 6 months ago


6 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 6 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>

6 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


Completed

Status changed to Awaiting Railway Response Railway 6 months ago



6 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.


5 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 6 months ago


Status changed to Solved userdeh 6 months ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...