Crons are running on the 54th second of the minute instead of the start?
Anyone know why my "every minute" cron is running on this weird timeframe? Shouldn't it on the minute and not 54 seconds into the minute?
8 Replies
IIRC Cron Triggers don't explicitly guarantee that they will run on the minute, so that looks normal
interesting. thats super odd. thanks for the clarity
It'll float around. You'll be on the same second of the minute until it switches data centers (usually every few hours), and then you'll be switched to being on a different second running from a different location
side note: Trying to run every person's minute cron exactly at the same time sounds like it'd cause major capacity issues on its own lol, imagine the load spikes
What I do is run a cron, and insert everything into queues. But having it run at the start of the minute is important for us unfortunately
Might be a better fit for Durable Object Alarms then? https://developers.cloudflare.com/durable-objects/api/alarms/
Cloudflare Docs
Alarms
Durable Objects alarms allow you to schedule the Durable Object to be woken up at a time in the future. When the alarm's scheduled time comes, the alarm() handler method will be called. Alarms are modified using the Storage API, and alarm operations follow the same rules as other storage operations.
I guess so. But every other cron works by running on the minute. So I just assumed cloudflare was the same
@Hard@Work are there issues with 10, 100s of thousands of alarms? How are alarms diff from queues in this particular case
Each DO can only set one alarm, but you can spawn as many DOs as you want
I guess Queues could work too, in the sense that the Queue Consumer could put a new message onto the Queue for the next run?
I guess it depends on what makes the best sense for your architecture