Hey, do you have a reproducible example (for example a dummy template)?

sure, try https://railway.com/deploy/derwSY

Hmmm, I am not sure if it's just the health check that is clashing with the start up dependency order, can you try putting the migration into a predeploy step and see if the predeploy step is actually executed after the database has been deployed?

sorry, what migration?

i dont have any migrations, or anything that i could possibly put into predeploy. i am a little confused here

I suppose the seeding of your database (your application is trying to perform some kind of migration at the start)?

yes, but those migrations only happen if the db connection is successfull otherwise it keeps retrying. its not a show stopper for us but i just thought that was the whole point of the startup ordering in Railway - to prevent that.

the database has a health check, but obviously its not http and thats all Railway supports

is it too much to ask for a startup order delay setting? X seconds after db starts ?

My theory is that the health check on your main service is clashing with the start up order. The start up order makes sure that the database is deployed before the main service is. However, since your main service has a health check, it means your service will actually run and do what it has to do before the status changes to deployed, essentially trying to access the database even if the database isn't deployed yet. Hence why I suggested to move the migrations to a predeploy step, which will potentially actually wait for your database to be deployed first before running the migration.