Hi! The only reason why I am not using Railway cron, is that I can’t set a parameter to be passed on execution. I have the same instance being called with different parameters. To avoid having many separate identical instances for every possible event, I needed to build my own scheduling system instead of the in-built cron. It would be great if we could have this small change, and I could throw all this away and use Railway cron.

Not a Railway engineer, but if I'd guess that adding an "param" to the cron job that you app could read would likely mean having to set a "Variable" (an environment secret) then trigger a redeploy to build the image with that new secret. You'd incur the downtime and required resources of having to redeploy each time. Then you could read that Variable each time your service started up.

You could actually write this yourself by having your app use Railway's Public GraphQL API to set a Variable on your service (variableUpsert mutation), and then trigger a redeploy. So each time you run an "event" you set a Variable on your service before shutting down so that it picks it up on the next trigger.

How often are you wanting to run a cron job and how many variations are there?

If you had a persistence layer, like a database, that would make things real easy. A really naive way to do it would be set up a Volume and write an event log to a text file or json file or something. Whenever your app boots up, read the last line of the file, and whenever you run an event you'd write to it. It might be easier than setting up a whole SQLite pipeline or something more complicated. Though, I suppose my suggestion here is equivalent to "[building] my own scheduling system" in a sense, which was what you're trying to avoid.