a month ago
Region/edge response header: x-railway-edge: railway/asia-southeast1-eqsg3a
App processing fast: x-process-time usually 0-466ms
External TTFB slow: 12.3s-15.9s
DNS/connect/TLS all fast, delay happens after TLS before first byte
IPv4 also slow, IPv6 does not resolve, so not client IPv6 fallback
We are seeing intermittent 12-16s TTFB on our Railway public domain:
The app itself is fast. Response header X-Process-Time is usually 0-466ms, and Uvicorn logs show /health and /auth/token finish within milliseconds to ~450ms.
Our service is configured with 1 replica in Southeast Asia (Singapore), not scale-to-zero. CPU and memory limits are 8 vCPU / 8 GB, so this does not look like a resource limit issue. We still see intermittent 12-16s TTFB on the public Railway domain while X-Process-Time is 0-466ms.
after deleting the old Singapore service, the only remaining service is smart-entry-v3 with multiRegionConfig.us-west2.numReplicas=1, but Railway still routes public requests through asia-southeast1-eqsg3a and TTFB remains ~12.6-12.9s while app x-process-time is 0-183ms for health endpoints.
The user observed browser security/interstitial behavior and 10s+ delay when opening railway.com as well. However, curl timing to our Railway app shows DNS/connect/TLS are fast and the delay is after TLS before first byte. Please check whether the up.railway.app ingress/domain routing or edge security layer for asia-southeast1 is causing intermittent 12s TTFB.
curl timing shows DNS/connect/TLS are fast, but time_starttransfer is intermittently ~12s even for /health and OPTIONS requests.
Examples:
- IPv4 /health: dns 0.089s, connect 0.163s, tls 0.318s, ttfb 12.408s
- IPv4 /health repeated: one request 0.109s, next request 12.311s
- default family: alternates between 0.488s and 12.3s-12.5s
- curl -6 cannot resolve host, so this is not a client IPv6 preference issue
Railway edge header:
x-railway-edge: railway/asia-southeast1-eqsg3a
Please investigate Railway edge/proxy/upstream scheduling between public ingress and the running container.
14 Replies
Status changed to Awaiting Railway Response Railway • 28 days ago
a month ago
Having the same issue on singapore, on a workspace in the hobby plan (pro plan workspace seems to work just fine)
Direct Railway Domain
▎ TTFB=12.212164s total=12.212907s http=404
▎ TTFB=12.155970s total=12.156168s http=404
▎ TTFB=12.129322s total=12.129601s http=404
▎ TTFB=12.109778s total=12.109992s http=404
▎ TTFB=12.121439s total=12.121831s http=404
Cloudflare proxied custom domain
▎ TTFB=15.393304s total=15.393666s http=404
▎ TTFB=15.227850s total=15.228043s http=404
▎ TTFB=15.236472s total=15.236701s http=404
▎ TTFB=12.353133s total=12.353864s http=404
▎ TTFB=13.754705s total=13.754996s http=404
a month ago
+1 experiencing the exact same issue from Taipei, Taiwan.
Same region (asia-southeast1-eqsg3a), same 12-16s TTFB pattern,
started today 2026-04-25 after a normal deployment.
My data points:
Latency test (5 consecutive requests to my NestJS API /api/products):
- Request 1: 12.35s
- Request 2: 12.20s
- Request 3: 15.21s
- Request 4: 12.21s
- Request 5: 12.23s
Headers:
- x-railway-cdn-edge: fastly/cache-nrt-rjaa8190038-NRT
- x-railway-edge: railway/asia-southeast1-eqsg3a
- X-Railway-Request-Id: mY-z_ISKTiWOzthLacI7Nw
Direct psql connection to my Postgres (same project, same region)
completes in 0.7s — DB is healthy.
Even 404 routes and non-DB endpoints are equally slow, confirming
the issue is not application-level.
Plan: Hobby.
Project: ai agent dashboard
Service: @aiagent/api at aiagentapi-production.up.railway.app
a month ago
+1 also having the same issues.
Currently on a hobby plan. Located in Vietnam.
Have deployed via Singapore and US West and still get the same data points.
Tested on a simple health endpoint and all requests are taking 12 seconds minimum.
a month ago
Exactly same issue here, all my endpoints +15 seconds response time
rustybrain
Having the same issue on singapore, on a workspace in the hobby plan (pro plan workspace seems to work just fine) **Direct Railway Domain** ▎ TTFB=12.212164s total=12.212907s http=404 ▎ TTFB=12.155970s total=12.156168s http=404 ▎ TTFB=12.129322s total=12.129601s http=404 ▎ TTFB=12.109778s total=12.109992s http=404 ▎ TTFB=12.121439s total=12.121831s http=404 **Cloudflare proxied custom domain** ▎ TTFB=15.393304s total=15.393666s http=404 ▎ TTFB=15.227850s total=15.228043s http=404 ▎ TTFB=15.236472s total=15.236701s http=404 ▎ TTFB=12.353133s total=12.353864s http=404 ▎ TTFB=13.754705s total=13.754996s http=404
a month ago
I'm in pro plan, and I got the same issue
a month ago
Having same issue
a month ago
same issue here for around 2 hours now. Consistent 15s response time.
Hope the issue gets fixed soon.
a month ago
{"status":"error","code":404,"message":"Application not found","request_id":"87unZzMsRWCH0IveoB_USg"}DNS: 0.070761s
Connect: 0.110846s
TTFB: 12.298104s
Total: 12.298337s
same here
a month ago
Same issue with a Singapore instance:
curl.exe -w "\nDNS:%{time_namelookup} Connect:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} Total:%{time_total}\n" -o NUL -s https://uw2a9fr6.up.railway.app/health
DNS:0.005396 Connect:0.066407 TLS:0.137245 TTFB:12.204283 Total:12.204349
a month ago
This has now been resolved.
The latency was caused by an issue with our CDN provider Fastly, specifically affecting their KV store in the Asia region. Their incident report: https://www.fastlystatus.com/incident/378503
Apologies for the disruption.
Status changed to Awaiting User Response Railway • 27 days ago
Status changed to Awaiting Railway Response Railway • 27 days ago
a month ago
Since the root cause was on Fastly's side (their KV store in the Asia region), it was tracked on Fastly's status page rather than ours. We'll look into whether incidents like this caused by upstream providers should also be reflected on our status page going forward.
Status changed to Awaiting User Response Railway • 27 days ago
a month ago
Railway is responsible for upstream provider choices; how would we know to check Fastly's incident page in the event of an incident? We didn't pick Fastly; you did.
Status changed to Awaiting Railway Response Railway • 27 days ago
a month ago
That's a fair point. You're right that upstream provider incidents that affect your services should be visible on our status page.
Status changed to Awaiting User Response Railway • 27 days ago
20 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 • 20 days ago