Project: unique-trust (7781d2fd-27ea-4db8-a3f0-aebd69e8b22a)

Service: transcriber (cb6663f9-c353-4b8d-927e-380841766034)

Environment: production

Custom domain: www.usetranscribe.io (CNAME → 3c1aubxi.up.railway.app)

Region: US West, 1 replica

Symptom (intermittent, recurring):

• TLS handshake to www.usetranscribe.io completes in ~25ms

• HTTP response never arrives (starttransfer=0, hangs until client timeout)

• Affects all paths: /, /healthz, /api/*

• Concurrent: GET https://3c1aubxi.up.railway.app/healthz returns

  404 in ~200ms — i.e. the platform edge is alive at the IP, but no

  service is bound to that Host header

curl evidence:

curl -o /dev/null -w 'code=%{http_code} starttransfer=%{time_starttransfer}s' \

https://www.usetranscribe.io/healthz

→ code=000 starttransfer=0.000000s total=15.006s (timeout)

curl -o /dev/null -w 'code=%{http_code} starttransfer=%{time_starttransfer}s' \

https://3c1aubxi.up.railway.app/healthz

→ code=404 starttransfer=0.215s

Recurrence: hit this twice in the past ~96 hours, neither during a

public Railway incident affecting routing. The June 11 image-registry

incident (OC3DGTST) coincided with the first occurrence; today's

(June 15) occurrence has no related public incident.

Resolution both times: clicking "Restart" on the active deployment

re-registers the edge mapping within ~30s. No code or env-var change

was needed. Container itself was healthy throughout (deploy still

marked ACTIVE, no crash loop in logs).

Ask: is there a known cause for the edge → container Host-header

binding dropping while the container stays ACTIVE? Anything we should

do differently — pin region, change healthcheck config, etc. — to

reduce recurrence?