16 days ago
Hi Railway team,
Note: The previous successful deployment and current stuck deployment use the same commit hash, so this does not appear to be caused by a code change.
Our production Rails app was working normally yesterday, but today it started returning "Application failed to respond".
Project ID:
275cf767-318f-45e0-88d7-1a95dbdd7596
Service:
klavy
Latest deployment ID:
3adabc34-ef3d-4019-84b1-104ec4b23a9a
Previous successful deployment:
51d86209-3982-4b0d-937e-c92de6eaafbf
Important detail:
Both deployments use the same commit hash:
7d20eaaf8ac15d3e0505881c81afc6e8af426e34
Region:
asia-southeast1-eqsg3a
Current behavior:
The build succeeds, image push succeeds, then deployment gets stuck in healthcheck.
Build logs show:
Starting Healthcheck
Path: /up
Retry window: 15m0s
Attempt #1 failed with service unavailable
...
Attempt #14 failed with service unavailable
Deploy logs only show:
Starting Container
The app is not reachable:
curl https://klavy.app/up times out.
Earlier runtime logs showed:
PG::ConnectionBad
connection to server at "postgres.railway.internal", port 5432 failed: Connection timed out
Postgres service appears Online/SUCCESS, and Postgres logs only show normal checkpoint logs.
Request IDs from failed app responses:
dZvqSC91QJyP0Wr_VOLIQQ
aHGq4nOjQJ-8iy_pacI7Nw
Could you check whether there is a private networking / deployment runtime issue affecting this service or region?
3 Replies
16 days ago
Update: The deployment logs now show the container failing during db:prepare before Rails starts.
Logs:
[entrypoint] Starting docker-entrypoint at Wed May 6 23:57:58 UTC 2026
[entrypoint] PORT=8080, RAILS_ENV=production
[entrypoint] jemalloc configured: LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
[entrypoint] Running db:prepare...
bin/rails aborted!
Tasks: TOP => db:prepare
ActiveRecord::ConnectionNotEstablished:
connection to server at "fd12:480b:70a9:1:9000:10:c329:641d", port 5432 failed: Connection timed out
connection to server at "10.169.100.29", port 5432 failed: Connection timed out
Caused by:
PG::ConnectionBad:
connection to server at "fd12:480b:70a9:1:9000:10:c329:641d", port 5432 failed: Connection timed out
This confirms the app container cannot reach the Postgres service over Railway private networking during startup.
Status changed to Awaiting Railway Response Railway • 16 days ago
16 days ago
Update: The new deployment eventually became Active.
The previous failed deployment was stuck at db:prepare with Postgres private network connection timeouts, but the latest deployment completed db:prepare/db:migrate and Puma is now listening on 0.0.0.0:8080.
The app is reachable again at https://klavy.app.
This seems to have been a transient Railway private networking/runtime issue rather than an application code issue.
15 days ago
The network configuration issue affecting your deployments has been resolved. Please try deploying again and let us know if you run into any further issues.
Status changed to Awaiting User Response Railway • 15 days ago
8 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 8 days ago