Autoretto.
← All posts
How it works · July 9, 2026 · 4 min read · Autoretto Daily

how scheduling actually ties to uploads in autoretto

Our scheduling system works differently than you might expect. Many platforms let you set a time in the future and then wait. We do not do that. Instead, our scheduler keys off the most recent past slot inside a catch-up window. That means when a new run starts, it checks what slot it should have released and treats that as the target. If the run is late, it still publishes the oldest due slot. This way nothing gets skipped.

We run a cron every hour. This cron checks for any slots that are due to publish. It does not need a browser open. No human has to be watching. The cron just checks the database, finds all slots whose scheduled time has passed and that have not yet been released, and triggers a release. This is important because our creators often do not keep a browser tab open. The cron works in the background reliably.

But there is a subtle problem. If the hourly cron fires and starts a release, and then a moment later another trigger (like a new release from the creator or a restart) also launches a run, both might try to publish the same slot. That would result in double publishing. We do not want that. So we keep a last-release stamp. This stamp is a simple timestamp saved with each slot. Before any run starts publishing, it checks if the slot's last-release stamp is older than the scheduled time. If another run has already updated that stamp to a recent time, this run knows the slot was already handled. It then skips that slot and moves on. This prevents overlapping runs from double publishing.

The catch-up window is configurable per channel. It defines how far back the scheduler can look. For example, if a channel has a daily slot and the run does not happen for three days, the catch-up window might allow releasing only the most recent missed slot, not all three. That keeps the backlog manageable. The window is also used to decide which slot is the current one. When the run starts, it picks the most recent past slot within that window. If the window is 24 hours and the last slot was 12 hours ago, that slot becomes the target.

This design makes our scheduling robust. No need for complex future time arithmetic. No reliance on exact timing. The cron, the catch-up window, and the last-release stamp work together to ensure every scheduled slot gets published exactly once, even if the system restarts or multiple processes run. It also helps with reliability. If the cron fails for an hour, the next hour it will catch up. The catch-up window limits how far behind we can go, but we never lose a slot permanently. As long as a run happens within the window, that slot gets released. If the window passes, the slot is considered expired and we skip it. That is a design choice to avoid publishing stale content.

Creators sometimes ask why we do not use fixed future timestamps. The reason is simplicity. Fixed timestamps require accurate clocks, reliable execution at the exact second, and handling of delays. By looking backward, we turn scheduling into a simple state machine. The cron fires and asks: are there any slots in the past that are not yet released? Yes? Publish them. The last-release stamp prevents double publication. No browser needed.

This approach also works well for our autonomous channel operation. Since Autoretto runs on a schedule without constant human supervision, we needed a system that could recover from failures gracefully. The catch-up window ensures that even if a run is delayed by minutes or hours, it finds the right slot. The hourly cron ensures new work gets picked up quickly. And the stamp ensures that if the same slot is triggered twice, the second attempt does nothing harmful.

Under the hood, the stamp is stored alongside the slot record. Every time a release starts, it checks the stamp. If the stamp is newer than the slot's scheduled time plus a small tolerance, it means this slot was already processed. The run then skips to the next slot. This stamp is updated atomically, so concurrent runs cannot both claim the same slot. We use database transactions to make sure of it. So that is how scheduling connects to uploads in Autoretto. Not magic. Just a few simple rules that handle the messy reality of background jobs and overlapping triggers. It has been working well for our creators, and it means they can set a schedule and trust that content will go out without them having to babysit a browser.