Project: welcoming-magic (ID f6b7b303-ac00-41d3-9d23-d8382db0296f), environment production (ID c715a6e0-806a-463a-b888-6b7299375235), service flint, domain flint-production-14c0.up.railway.app.

What we're seeing: after every push-triggered deploy today, the application itself becomes fully healthy in well under 15 seconds — but the public HTTPS domain doesn't route to the new deployment for several minutes afterward (sometimes longer). This has happened consistently across at least 4 separate deploys today (2026-07-17/18), not a one-off.

Concrete example from deploy aec6d9a:

Build scheduled: 2026-07-17T20:32:41Z

Image built and pushed: 2026-07-17T20:32:52Z (11s later, fully cache-hit build)

Container startup log:

2026-07-18T00:16:48Z Waiting for application startup.

2026-07-18T00:16:48Z [warmup] DB connection warm (0.09s)

2026-07-18T00:16:48Z Application startup complete.

2026-07-18T00:16:48Z Uvicorn running on http://0.0.0.0:8000

So the app was accepting connections instantly after container start.

railway logs (both --deployment runtime logs, and the app's own background threads — MQTT client, a scheduled materializer job) showed continuous, healthy activity the entire time.

Despite that, repeated curl requests to https://flint-production-14c0.up.railway.app/... returned connection timeouts (curl exit 28, no response within 10–15s) for several minutes before finally succeeding. One instance: external routing didn't come back until 17:22:14 local, roughly 5.5 minutes after the container had already been confirmed healthy via logs.

We've reproduced this same pattern (healthy container + logs, but external curl timeouts for minutes) across multiple deploys this session, with recovery times ranging roughly 1–10 minutes after the container was already confirmed live via logs.

What we've ruled out on our end:

Not a build/startup problem — build is fast (cache-hit) and Uvicorn binds in under a second after container start.

Not our network — curl to other HTTPS endpoints (e.g. google.com) succeeds instantly during the same window.

Not an app crash/restart loop — railway logs shows the same process continuously logging healthy activity (MQTT traffic, scheduled jobs) throughout the "unreachable" window; there's no restart between the timeouts and the eventual success.

Not DNS — resolves correctly and immediately.

Not resource starvation — we're on the Hobby plan; CPU/RAM usage during these windows is nowhere near Hobby's limits.

This looks like a known pattern reported elsewhere on Central Station — edge/healthcheck proxy losing its container mapping, or a TCP accept-queue/backlog issue at the Fastly/Varnish layer, where the container is verifiably healthy but external requests get no response for several minutes:

station.railway.com/questions/healthcheck-proxy-can-t-reach-containers-30db932a

station.railway.com/questions/railway-support-ticket-intermittent-500-fcb15906

Can you please check what's happening at the edge/router layer between a deploy going live and traffic actually being forwarded to it? It looks like there's a delay in cutting over external routing to the new deployment that's much longer than the deployment's own readiness. Happy to provide more deploy IDs/timestamps if useful — this has been reproducible essentially every time we deploy today.