How scheduling uses past slots to prevent double uploads

Scheduling uploads to YouTube sounds simple: pick a time and wait. But when you are automating a channel with no one watching the browser, that straightforward plan falls apart. A missed cron job or two overlapping processes can trigger a duplicate release. So we had to rethink the core logic of when and how a video actually gets published.

Instead of targeting a future timestamp, Autoretto's scheduler looks backward. It keys off the most recent past slot inside a catch-up window. That means it checks the last scheduled slot that should have already fired. If that slot has not yet been released, it releases it now. If it has been released, it moves on to the next one. This simple inversion avoids the classic problem of missing a deadline because the system was offline.

This approach effectively makes the scheduler self-healing. If a scheduled time passes while the system is down, the next run will catch up immediately. It does not skip because the future time is already past. It simply processes the slot as soon as it can. There is no need for complex backfill logic or manual intervention.

An hourly cron job drains any due slots in the background. This cron runs even when no browser or user session is open. It checks all channels for slots that fall inside the catch-up window. If a slot is due, it triggers a release pipeline. The cron is the heartbeat that keeps the schedule moving without requiring any active user presence.

But what if two cron jobs fire at once? Or what if a manual deploy happens while the cron is mid-run? That is where the last-release stamp comes in. Every channel has a last-release timestamp stored in the database. Before any run begins, the system checks that stamp. If the slot's scheduled time is older than or equal to the last-release stamp, it means the slot was already released. The run aborts immediately.

Here is a concrete example. Suppose a slot is scheduled for 2 PM. The cron runs at 2:01 PM and starts processing that slot. Before releasing, it writes a tentative lock. If another cron runs at 2:02 PM, it sees the lock and skips that slot. After the release completes, the last-release stamp updates to 2 PM. Now consider the next slot at 3 PM. If a run tries to release it but finds the stamp is already 3 PM or later, it knows the slot is already done and stops.

This design keeps the system stateless across individual runs but durable across crashes. There is no need to keep a scheduler process alive. If everything goes down, the next cron will catch up. It also eliminates any possibility of double publishing, even under race conditions. The stamp acts as a single source of truth that every process respects.

So scheduling in Autoretto is not about hitting a specific second in the future. It is about checking what should have already happened and making sure it happens exactly once. That is how your videos go live on time, every time, without a browser ever being open.