a month ago
Service: senis-suite (app.senis.cl)
Deployment IDs: f2732af8-f0cd-4da6-b222-83d796b8c466 (and the deployment immediately before it, same time window)
Time window: 2026-07-21 02:07–02:12 GMT-4
Symptom: All 11 healthcheck probes returned "service unavailable" over the 5-minute retry window, with zero HTTP requests reaching the container (empty HTTP logs) — despite gunicorn listening on 0.0.0.0:5000 within ~4 seconds and all DB migrations completing with no errors.
Context: The identical commit had deployed successfully ~22 minutes prior with no healthcheck issues. Host-header filtering has been ruled out on our end (Flask app, no ALLOWED_HOSTS equivalent, only werkzeug's ProxyFix which never rejects requests). Port binding is also correct (0.0.0.0:5000, matching the service's configured port).
Ask: Could you check your internal probe logs to confirm whether healthcheck probes were actually dispatched toward this service during that window? Trying to determine if this was a transient routing/probe-layer issue before re-enabling our healthcheck path.
2 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 month ago
17 days ago
Try without healthcheck
17 days ago
Yeah this smells like a routing/edge race, not your app. Zero HTTP logs but clean bind + healthy migrations basically rules out anything in your container — if gunicorn's up and listening, a real probe hitting that port would show up in your logs even if it got a bad response. The fact that nothing shows up at all means the request probably never left Railway's edge.
The "two deploys back to back, same window" bit is the tell for me. If the second deploy started before the first one's container was fully swapped/registered in the routing layer, you can get a short gap where probes get fired off but they're pointed at a target that's either gone or not live yet. That'd look exactly like this — "unavailable" with nothing hitting your app.
Also lines up with why the exact same commit worked fine 22 min earlier — that one wasn't racing another deploy.
Couple things worth checking on your end:
was that second deploy you manually triggering a redeploy/rollback while the first was still rolling out, or two separate git pushes close together?
can you repro it with a single deploy, no overlap? if it only happens when they're back to back, that basically confirms it
This is gonna be on Railway's side though — probably need someone to pull control-plane logs for those two deployment IDs and check when the container actually got registered as a target vs when the probes fired. Not something you can see from the app side unfortunately.