Past slots, not future timestamps: how scheduling works

There is a question creators ask early: how does Autoretto know when to upload? The obvious answer would be a calendar that counts down to the next slot. The real answer is more strange and more forgiving. The scheduler does not wait for a future timestamp. It looks at the most recent slot that has already passed. If that slot is due and has not been filled, it becomes the next publish target.

Imagine a channel set to publish every day at noon. At 4 p.m. the scheduler wakes up. Noon has passed, so that slot is the most recent past slot. If the upload did not happen yet, that slot is due. A catch-up window makes the search safe. The scheduler only looks back so far, maybe six hours or a day depending on the channel plan. Anything older than that window is treated as gone, not something to catch up on.

Catching up does not require a human to open a browser. Autoretto runs an hourly cron that checks the state. If the most recent due slot is unfilled, the cron drains it. It pulls a finished release, quality checks it, and sends it to YouTube using the stored consent and credentials. This happens on our server, quietly, whether the creator is asleep or in a meeting.

The clean part is preventing a second run from publishing the same release. An hourly cron can overlap with an on-demand run triggered by a creator pressing a button. Both checks might see an unfilled slot. That is where a last-release stamp comes in. The stamp records the time of the last release that actually went out. Before any publish, Autoretto reads the stamp and checks it against the most recent due slot.

If the stamp is older than the slot, the slot is truly due. If the stamp is equal to or newer than the slot, the slot is already handled. This sounds trivial, but it matters in a race. Two processes can read the same "due" answer at the same moment. Without a shared stamp, both would upload. With it, the first process writes the stamp before the upload finishes, and the second process sees the updated stamp and backs off.

The stamp also gives the scheduler a clean way to recover from a failed upload. If a YouTube API call times out, the stamp stays old. The next cron run sees the slot is still due and retries. If the upload actually went through but the API call failed to return, the stamp still might not have been updated. That is a double-publish risk. Autoretto handles this by verifying the upload through YouTube's video list before writing a new stamp.

All of this happens under the hood, but the effect is simple for a creator. You set a cadence, and the scheduler catches up when it can, never publishes the same slot twice, and does not need you to be present. The design is deliberately backward-looking. Instead of asking what time it will be, it asks what time has already passed and what is still owed. That keeps the system robust when nothing else on the internet is.