25 days ago
Service: editorial-app-production (project id 235a9ae6-3022-4927-a4ca-4142c68367de, service id 28a3024a-ddf4-418d-aa29-7b6ec94c0f31)
The deployment shows as "Active" and the deploy logs confirm gunicorn starts successfully and listens on 0.0.0.0:8080, matching the port shown under Networking. However, every request to both my custom domain (gestio.editorialgerminar.com, CNAME to editorial-app-production.up.railway.app) and the raw editorial-app-production.up.railway.app domain returns an "upstream error", and no new log line appears in Deploy Logs when the request is made — meaning the request never reaches the container. I performed a manual restart of the service (fresh clean boot confirmed in the logs at 09:51 UTC) and the issue persists identically. I've ruled out DNS (CNAME confirmed correct), client network/browser (tested on 2 networks + private browsing, same result), Serverless/sleep (disabled), and there's no reported platform-wide incident. Could you check the routing/proxy state for this service?
I also found a similar report in this Discord (thread: 'Evidence: nucleus replicas unresponsive while Railway reported 12/12 active') describing the same dashboard-vs-reality mismatch (service shown as active/healthy while unresponsive) — might be a related underlying issue.
Pinned Solution
25 days ago
Can you run the command curl -v http://localhost:8080 from the Console tab and check if that returns your app? If it does, then we can rule out issues with your app. Also, FWIW, try to use --bind 0.0.0.0:$PORT, and set the PORT=8080 in your service variables. It's also recommended that you configure a healthcheck path to ensure your app is ready to accept connections (healthchecks require the PORT variable to be set).
4 Replies
25 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 25 days ago
25 days ago
Update: ruled out a hidden startup crash too
Added PYTHONUNBUFFERED=1 to force unbuffered output, to rule out a silent crash being swallowed by output buffering. The full startup sequence now shows cleanly, with no gap:
Starting gunicorn 23.0.0
Listening at: http://0.0.0.0:8080
Using worker: gthread
Booting worker with pid: 4
BASE DE DATOS: PostgreSQL — postgresql://postgres.railway.internal/railway
Flask-Limiter: using Redis as shared backend
Starting Container
Migraciones de columnas aplicadas correctamente.
Scheduler: jobstore SQLAlchemy configurat
Added job "Recordatoris automàtics a llibreries" to job store "default"
Scheduler started
Scheduler iniciat — recordatoris diaris a les 9:00h
The app reaches a fully healthy, ready state — DB migrations applied, background scheduler running, zero errors. I then loaded the public URL and got "upstream error" again, with zero new log lines appearing at that moment.
At this point I believe every application-level cause has been ruled out with direct evidence (correct $PORT binding, dependencies present, clean unbuffered startup, no crash, fresh service reproduces the same issue). This looks like a routing/proxy issue on Railway's side that isn't reaching either of my two services. Any update on this would be very much appreciated — this has been down for several days now and it's a business-critical app.
25 days ago
Can you run the command curl -v http://localhost:8080 from the Console tab and check if that returns your app? If it does, then we can rule out issues with your app. Also, FWIW, try to use --bind 0.0.0.0:$PORT, and set the PORT=8080 in your service variables. It's also recommended that you configure a healthcheck path to ensure your app is ready to accept connections (healthchecks require the PORT variable to be set).
darseen
Can you run the command `curl -v http://localhost:8080` from the **Console** tab and check if that returns your app? If it does, then we can rule out issues with your app. Also, FWIW, try to use `--bind 0.0.0.0:$PORT`, and set the `PORT=8080` in your service variables. It's also recommended that you configure a healthcheck path to ensure your app is ready to accept connections (healthchecks require the `PORT` variable to be set).
25 days ago
Thanks for the curl suggestion — it's what pointed us away from Railway's infrastructure and toward the actual bug in my own code.
xaviforc
Thanks for the curl suggestion — it's what pointed us away from Railway's infrastructure and toward the actual bug in my own code.
25 days ago
You're welcome! Glad you found a fix.
Status changed to Solved mayori • 25 days ago