2 months ago
We have a number of mission-critical cron jobs running on Railway. Earlier this week, we noticed that all of our cron jobs stopped running on the expected schedule. Instead, they seem to be "stuck".
In one case, a less critical cron job got stuck two weeks ago. Many of our cron job got stuck around 2025-12-04 23:00 UTC last week.
Inspecting a cron job that is stuck, we find that:
- The deployment is still active in the Deployments tab
- The Cron Runs shows the next schedule run correctly
- At the scheduled time the job doesn't run
- There is no log output associated with the new run
- The Recent Executions doesn't show the new run, only the "stuck" run
We have also observed that:
- The behavior was noticed on multiple cron schedules, so from a cron job set to run every 5 minutes, and a cron job set to run every hour
- This is not due to leaked resources blocking process shutdown, as we have reproduced the issue with a simple "hello world" script that only prints a message to stdout.
- This is not because the services are still running, all execution times for previous runs are < 1min
- It's not just a delay in execution (some forum threads said that cron jobs can have some delay ~20s depending on their priority from Railway), but rather a failure to execute, with some jobs having last run 5 days ago.
- When we redeploy the relevant cron service, it may run on the set schedule several times, but at some point it will typically stop executing after a while.
- On any of the services that are stuck, they are also unable to run via manual triggering through the UI, so on clicking "Run Now", we get a "failed to invoke cron execution"
- This happens in different environments across different workspaces and in different regions.
- Many of our cron jobs are in EU West but we also have seen the issue in US West.
10 Replies
Status changed to Awaiting User Response Railway • 2 months ago
itsrems
Hi, could you share a link to your service or project?
2 months ago
Sure here is an affected project https://railway.com/project/e59adfc7-3ac8-4f85-8085-bda7174cd6d3?environmentId=ce5508b9-5d61-43f2-8902-c69dbc56a556
Status changed to Awaiting Railway Response Railway • 2 months ago
2 months ago
Hello!
We're acknowledging your issue and attaching a ticket to this thread.
We don't have an ETA for it, but, our engineering team will take a look and you will be updated as we update the ticket.
Please reply to this thread if you have any questions!
2 months ago
We're aware of an issue with crons defined using railway.json / config as code.
Our team is working on a fix - in the meantime, could you try removing the cron schedule from your config as code file and setting it from the dashboard instead?
Status changed to Awaiting User Response Railway • 2 months ago
itsrems
We're aware of an issue with crons defined using railway.json / config as code.Our team is working on a fix - in the meantime, could you try removing the cron schedule from your config as code file and setting it from the dashboard instead?
2 months ago
It's good to hear that you have identified the problem, which seems to be related to defining cron jobs in configuration.
I've switched the Cron Schedule for a test job from railway.conf's deploy.cronSchedule to set it manually in the web interface. But it's too early to tell if this is an effective workaround, I would like to check back after a couple of days.
In the long-term, manual configuration is not aligned with our gitops strategy, as we manage a growing number of cron jobs, and we really need to have our configuration checked into the relevant git repo to allow change controls and auditing.
Do you have an ETA on when the railway.conf config-as-code cron definition can be fixed?
Status changed to Awaiting Railway Response Railway • 2 months ago
2 months ago
I don't have an exact ETA, but we have a fix in flight and being tested this week.
Status changed to Awaiting User Response Railway • 2 months ago
2 months ago
I can confirm that deleting deploy.cronSchedule from a job's railway.conf and then setting it manually in the web interface does seem to result in jobs that are able to run on the correct schedule for at least the past week, in contrast to jobs that rely on config-as-code. However as our team uses Gitops as part of the development process, this is not a long-term solution and it becomes unwieldy and error-prone with increasing number of jobs, so we hope this can be fixed in railway.conf.
Status changed to Awaiting Railway Response Railway • 2 months ago
2 months ago
Thank you for confirming the dashboard workaround is working for you! Totally get that manually configuring cron schedules doesn't fit your GitOps workflow, especially as you scale up. Version control and auditability are important for managing multiple jobs reliably.
We don't have a specific timeline on this yet but in the meantime, the dashboard workaround should handle any critical cron jobs. Please keep an eye on our changelog and you'll see it there as soon as it ships.
Best, The Railway Team
Status changed to Awaiting User Response Railway • 2 months ago
Status changed to Solved chandrika • 2 months ago
2 months ago
✅ The ticket Scheduled Tasks Issue has been marked as completed.