viewer_api service — startup loop, Application failed to respond
timvonsachs
HOBBYOP

a month ago

Hi Railway team,

My FastAPI service viewer_api has been unreachable for ~26 hours.

Edge responds with HTTP 502 and "Application failed to respond",

but deploy logs show clean startup. I cannot identify the root cause

from the logs alone and need your help.

## Request IDs from failed requests

- Yesterday (first observed): 7RHj10r5SK6dset6N8N_Fg

- Today: m0zYO2TIQECRCKHam3z_FQ

## Service

- Project: [DEIN_PROJECT_NAME hier einfügen]

- Service: viewer_api

- URL: https://api-production-9a90.up.railway.app

- Region: europe-west4-drams3a

## Symptom

External requests to any endpoint return:

HTTP/2 502

x-railway-fallback: true

{"status":"error","code":502,"message":"Application failed to respond"}

## Deploy logs (latest deploy)

Logs show clean startup followed by unexplained shutdown/restart cycle:

Starting Container

INFO: Started server process [1]

INFO: Waiting for application startup.

INFO: Application startup complete.

INFO: Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)

INFO: Shutting down

INFO: Waiting for application shutdown.

INFO: Application shutdown complete.

INFO: Finished server process [1]

INFO: Started server process [1]

INFO: Waiting for application startup.

INFO: Application startup complete.

INFO: Uvicorn running on http://0.0.0.0:8080

INFO: Application shutdown complete.

INFO: Finished server process [1]

INFO: Shutting down

...continues in loop

No exception, no crash trace, no explicit error. The process starts,

binds to 0.0.0.0:8080, completes startup, then gets terminated externally.

## What I have already checked / tried

- Health check settings in Railway dashboard

- Port binding (app binds 0.0.0.0:8080, which was working before)

- Postgres connection (DB reachable and fast via psql from my machine)

- No code deploy changes that would plausibly cause this

- Service was working normally ~26 hours ago, no major env var changes

since then

## What I need

1. Root cause analysis — why is the container being terminated?

2. Whether this is an edge routing issue, health check issue,

platform-side issue, or app-side issue I'm missing

3. If platform-side: status / ETA for fix

4. If app-side: what signal I'm missing that would explain the shutdowns

This is a production service blocking my launch preparation.

Fast response appreciated.

Thanks,

Tim

$10 Bounty

4 Replies

Status changed to Open Railway about 1 month ago


Something I’d try is to hardcode the application to listen to port 3000, and map your URL to 3000 as well.


beta1295
FREE

a month ago

Cambiar del puerto 8080

Al asignado


beta1295

Cambiar del puerto 8080 Al asignado

Please keep responses in English.


0x5b62656e5d

Something I’d try is to hardcode the application to listen to port 3000, and map your URL to 3000 as well.

timvonsachs
HOBBYOP

a month ago

did not work :(


Welcome!

Sign in to your Railway account to join the conversation.

Loading...