a month ago
I am at my wits end and cannot see where I went wrong.
I have the following services up and running
Redis
Postgres
api-backend (laravel with php-fpm/nginx)
All are linked and operational. The api backend is deployed using a docker image I build on my private repo.
I had launched it without the health-check endpoint set to /health and it runs just fine b/c I can hit the endpoint with a browser and a curl command from terminal.
Terminal commands I attempted:
curl -I http://localhost/health -> 200 OK
curl -I https://<private>.up.railway.app/health - 200 OK
I had also, ssh'd into the instance to see if the proper ports are exposed (via netstat) and I saw that they were. Given the curl command working from before, I'm not surprised. But, for good measure, I also ran curl there as well curl -I 0.0.0.0/health -> 200 OK
Under the build logs All I saw was the following:
```
==================== Starting Healthcheck ====================
Path: /health
Retry window: 30s
Attempt #1 failed with service unavailable. Continuing to retry for 29s
Attempt #2 failed with service unavailable. Continuing to retry for 28s
Attempt #3 failed with service unavailable. Continuing to retry for 26s
Attempt #4 failed with service unavailable. Continuing to retry for 22s
Attempt #5 failed with service unavailable. Continuing to retry for 14s
1/1 replicas never became healthy!
Healthcheck failed!
```
The service launches in roughly 20sec without the health check so, imho, 30s should be enough time to validate service health.
I could use some advise or perhaps some assurance that I'm not the only one with this issue and that it's on top of someones mind at railway.
8 Replies
a month ago
Status changed to Awaiting User Response Railway • about 1 month ago
a month ago
Unfortunately, after setting PORT to 80 it did not succeed in the health check. Port 80 is the port the image/container listens on b/c of the embedded nginx service running inside.
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month ago
The logs don't indicate that a server was started. Are you sure you have the right start command set?
Status changed to Awaiting User Response Railway • about 1 month ago
Status changed to Awaiting Railway Response Railway • about 1 month ago
Status changed to Awaiting User Response Railway • about 1 month ago
a month ago
Ok, I see what you mean. So, I checked the currently running instance and the logs do indicate a started service:
--
Starting Container
2026-01-23 20:33:55,842 INFO Set uid to user 0 succeeded
2026-01-23 20:33:55,844 INFO supervisord started with pid 1
2026-01-23 20:33:56,846 INFO spawned: 'nginx' with pid 2
2026-01-23 20:33:56,847 INFO spawned: 'php-fpm' with pid 3
[23-Jan-2026 20:33:56] NOTICE: fpm is running, pid 3
[23-Jan-2026 20:33:56] NOTICE: ready to handle connections
2026-01-23 20:33:57,873 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2026-01-23 20:33:57,874 INFO success: php-fpm entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
127.0.0.1 - 23/Jan/2026:20:34:16 +0000 "GET /index.php" 200
--
However, this is the instance where I deleted the healthcheck endpoint.
So, when I set the endpoint why is the instance not starting?
You had mentioned something about a "start command"? I don't see that comment anymore. I don't have a start command b/c my Dockerfile contains the default start command CMD ["/usr/bin/supervisord", "-c", "/etc/supervisord.conf"] which initializes both php-fpm and nginx so it's not necessary. I could be wrong about it being necessary or not, you tell me.
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month ago
It works!! I don't fully understand all the factors involved (yet) but I think there are at least 2 that helped make this work. First, your suggestion to set the PORT to what the service is expecting to receive requests on, for me this was port 80. The second one is changing the EXPOSE 80 443 9000 directive in the Dockerfile to just be EXPOSE 80. Rookie mistake on my part. DepOps is not my strong suite, haha. There could be other factors but I suppose this is better than not having a working api service. Thanks for the assist!
Status changed to Solved Anonymous • about 1 month ago
a month ago
Our platform does not utilize the EXPOSE keyword in any way. What fixed it was likely you removing your php artisan health:check start command.
Status changed to Awaiting User Response Railway • about 1 month ago
a month 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 • about 1 month ago