Our services (project: our project, services: Head-office & Branch, region: Southeast Asia / asia-southeast1) have been experiencing intermittent 1-3 second delays on random API requests since around June 30.

Client-side Resource Timing shows the entire delay is TTFB: queue = 0ms, DNS = 0ms, connect/TLS = 0ms (established connection reused), then 1,100-2,800ms waiting for the first response byte. Meanwhile our origin's internal processing time (measured in-app and exposed via a response header) is only 1-20ms for the same requests. The pattern is intermittent — most requests complete in ~150-200ms, then a random one takes 1-3s.

Reproduced from 4 different client networks in Korea (edge: hnd). Origin keep-alive is disabled on our side (Node keepAliveTimeout=0), so this is not a stale-connection issue at the origin.

Sample affected request IDs (x-railway-request-id), all from 2026-07-04 (KST, UTC+9):

• hND27rtmTX--HUyxipRofQ (client 1,973ms / origin 1ms)
• q0-ePZLORCCR-v5fipRofQ (client 1,434ms / origin 1ms)
• Hr5aubcUTJWxTuV4acI7Nw (client 2,802ms / origin 18ms)
• gYUbOwImQwOXjx3vipRofQ (client 1,144ms / origin 1ms)
• mzZ8knmpSpGpKD5LacI7Nw (client 1,143ms / origin 7ms)

This signature (fast DNS/connect/TLS, delay entirely in TTFB, origin processing under 20ms) matches the Fastly Asia incident reported in the thread "Intermittent 12-16s TTFB on Railway public domains" (resolved as Fastly incident 378503). Our case is milder (1-3s, intermittent) and started around June 30, so it appears to be a separate, ongoing degradation in the same layer. Could you trace where the requests above spent their time within Railway's edge/routing layer, and check whether Fastly's Asia edge is degraded again — since vendor-side issues don't appear on your status page?