Service responding 12-15s TTFB on every request, regardless of handler
ashish-frozo
PROOP

16 days ago

Project: edgegate (8876e48e-59a0-40e0-ab88-c3a21d8e1ee0)                                                                                        

  Environment: production                                                                  

  Service: frozo-frozo-qualcomm-aihub (c05bdba4-... — backend FastAPI)                                                                            

  Region: asia-southeast1-eqsg3a                                                                              

  Every HTTP request to this service takes ~12-15s TTFB regardless of handler, method, or status code. Verified:                                  

   - GET /health (returns {"status":"ok"}, no DB/Redis): 12-15s                                                                                    

   - GET /nonexistent (404): 15s                                                                                                                   

   - POST /health (405): 15s                                                                                                                       

   - 5 parallel requests: all complete in 12-15s, not queued                                                                                       

   - 10 sequential requests immediately after fresh deploy: every one 12-15s (not cold-start)                                                      

   - Same delay on *.up.railway.app direct domain and on the custom Cloudflare-fronted domain                                                      

   - uvicorn boot logs show app listening on 0.0.0.0:8080 correctly, matching targetPort: 8080                                                     

   - Sister service edgegate-frontend in same region/project responds in 100-300 ms                                                                

   Sample slow request IDs from x-railway-request-id: MEhvTR4GQBe7UKLdacI7Nw                                                                       

   Critical timeline: I have a partnership-meeting demo on Tuesday and need this resolved.

Solved

1 Replies

Status changed to Awaiting Railway Response Railway 16 days ago


15 days 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 15 days ago


Railway
BOT

8 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 8 days ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...