I had this problem where on deployment the app had to do some preliminary queries to the database but the app was crashing 2 out 10 times on startup because it was not able to establish the connection to DB at all, because of operational error (device not known or something). The app starts but there's no DB on the designated host and port. Internal host btw.

But not only that, even if the app started it would randomly stop working (not crashing) and start timing out all of the requests. In the DB logs I would see:

"unexpected EOF on client connection"
"could not receive data from client: Connection reset by peer"

I read somewhere in Railway docs that I should sleep the deployment for 3 seconds (in the deployment command) so the Railway network to be able to sort out the connection to DB (PostgreSQL in this case). I did that but the problem persisted intermittently. So I removed the preliminary DB querying to avoid the app crashing on startup.

However, I am now in this weird situation where the debugging is impossible. The app deploys fine bit then randomly (after days or even weeks) starts timing out on all paths and in the DB I would see:

"unexpected EOF on client connection"
"could not receive data from client: Connection reset by peer"

The app does not produce any errors in the deployment logs and does not crash, but just returns foul HTTP responses (499 - client has closed the request before the server could send a response or 502 - failed to forward request to upstream: connection dial timeout).

I would have expected to see some warnings, errors or exceptions in the deployment logs, but there's nothing. The deployment logs just stop with the last known 200 response from the app, while the HTTP logs continue with bad responses. Also the timing out happens on ALL URL paths, which of course ALL require a trip to the DB.

The debugging seems impossible because the problem is not reproducible and it's intermittent. I could be wrong, but I am pretty sure there's something with the DB connectivity.