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

• 📚 Deploy a Ruby on Rails App

• 🧵 Cron Runs on Old Deployment

• 🧵 Frontend Deployment Issues After Supabase Edge Functions Integration - Site Not Loading

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

I see successful logs.

Can you please share a screenshot, logs, or links to the errors you're seeing?

Best,

The Railway Team

That's why it's difficult to debug. There's no errors on the server. Everything appears to log fine, but the cron job is not responsive when it should be triggered.

Can you expand on what you mean that the cron job is unresponsive?

To debug, we'll need to understand where the issue with Railway lies to ensure it's not at the application level.

Hey support Team

We are currently having some issues with restarting the container every 5 minutes. It has been working well but this issue just started yesterday.
Service: learnway-transaction-processor
Logs below:

I am going to need a bit more information on what you are trying to accomplish here. Are you trying to restart the container directly from within the workload?

So, for context, this is a stand-alone deployed service that is meant to ONLY run a cron-job every 5 minutes. The cron-job runs every 5 minutes, but for some days now, it has taken more time to process the cron-job process. Meaning that after 5 minutes, a new cron-job is supposed to run, and that cron-job has not being consistent, sometime it runs for 14 minutes, other times 10 minutes, other times 7 or 8 minutes, other times it runs for 2 minutes, other times it runs in 3 seconds. Early in the day yesterday, some of the cron-jobs ran for more than 10 minutes, but around noon yesterday, it ran faster and that continued till yesterday evening. Early today (13th November, 2025), the execution time also ran faster ranging from 4 seconds to about 4 minutes max, fast forward to about 11am till now, the transaction has also ran for much longer, from about 8 to 14 minutes in most cases.

This is basically how inconsistent it has been.

Here are some screenshots from yesterday and today to help with more information.
Unfortunately I can't send multiple screenshots here.
But here is an image of the current log.

Here us another example of the inconsistency. Notice the first two logs. You will see that the latest one is resolved, but the transaction before the latest one is still running, and also for more than 10 minutes.

2025-11-13T16:20:48.000000000Z [inf] Starting Container
2025-11-13T16:29:29.000000000Z [inf] Starting Container
2025-11-13T16:34:22.000000000Z [inf] Starting Container
2025-11-13T16:41:00.000000000Z [inf] Starting Container
2025-11-13T16:46:03.000000000Z [inf] Starting Container
2025-11-13T16:52:31.000000000Z [inf] Starting Container

Noted, crons sometimes are indeed staggered because it uses the whole global execution, but we're tracking this as we are fixing it. It won't be to the second, but it shouldn't be wildly off tolerance like that.

Known and working on it.

The service has been stuck in the “Starting container” state for the past 10 hours.

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!

Update: going to see if it's a core backend issue on our side. I did spend time to investigate the queue and it seems fine but I will need further time to see where the root issue is. I appreciate your patience on this matter.

🛠️ The ticket Scheduled Tasks Timing Issue has been marked as triage.