How scheduling actually turns into uploads now

You might think a scheduled upload means the system picks a future time, waits, then publishes. Autoretto does not do that. The scheduler keys off the most recent past slot inside a catch-up window. That sounds upside down, but it fixes a few real problems.

Here is the issue with future timestamps. If the platform goes down for an hour, or a run gets stuck, the scheduled time passes. When the system comes back, it has to decide what to do. Does it publish late? Does it skip? Does it try to catch up? Autoretto's answer is simple: it looks at the last published slot and the current time.

The scheduler works with a catch-up window. This window defines how far back a missed slot is still worth publishing. If a slot is inside that window, the system treats it as due. If it is older than the window, it gets dropped. The window is not a timer. It is a boundary.

A cron job runs every hour. It does not need a browser open. It sweeps through the schedule and finds all due slots. Due means the most recent past slot that has not been published yet. For each due slot, it triggers a release. Once the release finishes, the scheduler marks that slot as done and moves on.

Why past slots instead of future ones? Because the cron is not waiting. It is catching up. If you publish at 9 AM, 11 AM, and 1 PM, and the system misses the 11 AM slot, the next cron run at 1:30 PM sees that the most recent past slot is 11 AM. It publishes that one first. Then it sees 1 PM is due, and publishes that too. If the window is two hours, a 9 AM missed slot would be too old by 1:30 and get skipped.

This design keeps things simple. There is no need to store a long list of future triggers. The schedule is just a pattern. The actual publishing is driven by a background job that constantly asks: what is the most recent past slot I have not covered? That question does not require a browser, a user, or a front-end session. It only requires the database.

There is one more guardrail. Every release has a last-release stamp. This stamp records the exact time the last release completed. When a new run starts, it checks the stamp before doing anything. If the stamp is newer than the start of the run, the run aborts. This prevents two overlapping runs from both deciding they need to publish the same slot.

Overlapping runs happen more often than you would think. The hourly cron can collide with a retry, or a manual push from the dashboard. Without the stamp, you end up with double uploads or a corrupted state. With the stamp, the second run sees that the first one already finished and simply stops. It is a small check, but it saves a lot of trouble.

So the scheduler is not a fancy future-timer. It is a backward-looking cleaner. It looks at what was supposed to happen, checks the stamp, and fills the gap before the window closes. That is how scheduling connects to uploads now. It is less glamorous than a countdown clock, but it works.