Project: aski-app (environment: production)

Service: aski-app (custom domain: api.aski.dev, region: US West)

Plan: Hobby

SUMMARY

Requests over a NEW TCP/TLS connection intermittently take 4–27s to first byte (TTFB),

while requests over a REUSED (keep-alive) connection are consistently <0.6s. This affects

even a trivial endpoint (GET /health, which just returns a static JSON, no DB/IO), so it is

not application logic. It looks like the edge proxy ↔ container connection establishment is

intermittently slow.

EVIDENCE

1. New connection per request (curl, sequential):

   $ for i in $(seq 1 6); do curl -s -o /dev/null \

   -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n" \
   
   https://api.aski.dev/health; done

   dns≈0.005s tcp≈0.09s tls≈0.20s ttfb=5–27s <-- TLS fast, TTFB huge

   (Observed: 25.2s, 7.5s, 22.8s, 3.0s, 1.5s, 26.8s)

2. Same endpoint, 6 requests over ONE reused connection (keep-alive):

   $ curl -s -o /dev/null -w "ttfb=%{time_starttransfer}\n" \

   https://api.aski.dev/health https://api.aski.dev/health ... (x6)

   ttfb = 0.18s, 0.20s, 0.30s, 0.35s, 0.57s, 0.59s <-- always fast

WHAT WE RULED OUT (app side)

• CPU/RAM: replica limit 8 vCPU / 8 GB; actual usage ~0.2 vCPU / ~150 MB (idle).

• App: /health does no DB/IO; same stall across 4 independent uvicorn workers.

• Endpoint logic, DB (internal postgres.railway.internal), background jobs (moved to a

  separate service). All ruled out.

• A full service Redeploy did NOT change the behavior (so not a single bad node).

ASK

Please investigate latency in establishing NEW connections from the edge/proxy to this

service's container (proxy↔container connection setup / pooling). The container responds in

<0.6s once a connection exists; the delay is entirely in getting the first response on a fresh

connection. Happy to run any diagnostics you need.