How the scheduler catches up when no one is watching

Scheduling an upload sounds easy. Pick a time. Trust the system to handle it. But the old way had a flaw. It depended on a future timestamp being reached while the app was open. If your computer slept, if your browser closed, if you simply forgot to keep the tab alive, that timestamp came and went, and nothing published. That was a broken promise.

We built the scheduler differently now. It does not look ahead. It looks back. The starting point is a recent slot in your schedule that has not yet been published. That slot lives inside a catch-up window. The window is a span of time after the slot's intended moment. As long as the slot is inside that window, it is still considered due and ready to go. Once you have slots spaced hours apart, a catch-up window of a few hours gives the system room to breathe.

Here is the sequence. Say a slot is scheduled for 3:00 PM. At 4:15 PM the hourly cron fires. It checks the schedule. The 3:00 PM slot is now the most recent past slot that has no publish stamp after it. It is inside the window. The cron decides that slot is the one to work on. There is no future time to wait for. The slot is already late. Being late is fine. The scheduler's job is to catch up. Because the window is based on past time, a computer that wakes up at 6:00 PM can still catch a slot from 2:00 PM, provided the window is still open. It will publish that slot as soon as it can, then mark it done and move on.

The hourly cron is the engine. A cron job is a simple scheduler built into the server. It has been running quietly every hour since we deployed it. It does not open a browser. It does not require the desktop app. It just calls a function that checks the schedule and the slot state. When a due slot exists, the cron starts the pipeline. That pipeline renders or fetches the latest video, runs the quality and policy gates, and sends the upload to YouTube. No human needs to click anything.

This is how channels keep publishing even when nobody is watching. The cron is the steady heartbeat. The catch-up window decides how far back it will reach. A slot that is a few hours old is fine. A slot that is days old is skipped. The skip matters. It prevents a pile of stale videos from being uploaded all at once after a long downtime. It also keeps the channel regular when everything works.

The last-release stamp handles the race. Two runs can both see the same due slot. One might be the cron from the server. The other could be you clicking a button in the app. Both are legitimate. Both are ready to go. The stamp is a small piece of state that records which slot was last completed. The first run reads the stamp, sees it matches the previous slot, and proceeds. It publishes and then advances the stamp to the slot it just completed. The second run reads the stamp a moment later and finds it has changed. That tells it the job is already taken. It stops. No duplicate upload. No double publish.

We made this change because we needed reliability. Autoretto is a platform that runs channels in the background. A creator sets a schedule and, in many cases, goes off to live their life. The system has to handle sleep, travel, and network gaps. By anchoring to the past rather than the future, we removed a whole class of failures. The cron is always allowed to be a little late. The worst case is a video goes up an hour late, not a video never goes up at all.

The result is that your schedule reads as intent, not a strict contract. If you are present, the app can publish on time or even early. If you are not, the cron will catch the slot before the window closes. And if you ever worry that two processes might both publish, the stamp has your back. We have been running this way for a while now. The channel keeps its rhythm.