Hey there! We've found the following might help you get unblocked faster:

• 🧵 Django ASGI Application 502 Errors - Procfile and Port Binding Issues - Health Check failure despite successful build
• 🧵 Error: '$PORT' is not a valid port number.
• 📚 Configure Healthchecks
• 🧵 502 Bad Gateway on preflight OPTIONS requests for stable, healthy service

If you find the answer from one of these, please let us know by solving the thread!

Hi @vishrut28, most probably in your server file, you might have declared a pre-configured port number, which Railway addresses as Magic/Target Ports. If this is the case, then you have to follow these steps:

a. Before deploying the service, add the PORT variable and use the port number that you are using in the server file.

b. In the healthcheck path setting, you can use /health or health (or whatever endpoint that you are using to do the healthcheck). The slash is not important

I did that on my Express server, and it was a success

The endpoint for your reference is:

app.get("/health", async (req, res) => {
  res.status(200).send({
    success: true,
  });
});

Furthermore, you can refer to this doc: https://docs.railway.com/guides/healthchecks#configure-the-healthcheck-port

Your current build-logs might be looking like this:

This is because of the fact that the PORT is not added as a variable for the Target Port

Do let me know, if you face any other issue

Thanks mate for the help!

The thing is, i tried this way, but still getting the same old error 😕

Can you please post the screenshot of build-logs, and one for your PORT environment variable, along with your app.listen code from express file.

Btw, we can also use "/" as the healthcheckup endpoint.

And also please provide the healthcheckup endpoint that you are using. Surely, we will resolve the issue

Any update, @vishrut28?

You can also check your healthcheckup timeout constant, by default it is 300seconds, if your healthcheckup endpoint do not return 200, then it fails, and send SIGKILL, which is exactly what is happening with you.

Can you please provide the screenshots that I asked earlier?

Any update, @vishrut28?

Hey, something that clicked for me is that the "Stopping Container" and SIGTERM logs that appear after a new deployment refer to the termination of the previous deployment's container, not the new one. Not sure if this is exactly what was happening to you but thought I'd mention this based on my experience.