Scheduled content is only as reliable as the mechanism watching the clock for it, and every so often that mechanism gaps — a server hiccup, a cron job that silently stopped, a restart that took a few minutes longer than expected. When that happens, due items don’t publish on time, and understanding what actually happens once a gap stretches past roughly thirty minutes matters for knowing whether you need to intervene or just wait.
What "Missing a Slot" Means
Every scheduled item has a target time. Under normal operation, the every-minute scheduler check notices the moment that time arrives (or shortly after, within the same minute) and publishes it. A missed slot means that target time has passed and the check either hasn’t run at all, or has run but something prevented it from picking the item up — most commonly because the underlying scheduler tick itself has stopped firing (see “How the Every-Minute Scheduler Actually Publishes Your Posts” for how that tick is supposed to work).
The 30-Minute Threshold
A short delay — a minute or two past the target — is normal and expected; it’s just the natural resolution of a check that runs once every sixty seconds rather than continuously. But if the gap stretches well beyond that, past roughly the thirty-minute mark, the system treats it differently: rather than quietly publishing something dramatically late as if nothing happened, an item that’s missed its window by that much gets parked, defaulting to a conservative “needs a decision” posture instead of auto-publishing something that’s now significantly out of sync with when it was actually meant to go live.
That default matters, because auto-publishing something thirty-plus minutes late without any flag would be the wrong behavior in a lot of cases — a post meant to coincide with a launch or an announcement is far less useful if it goes out silently half an hour (or more) after the fact with no indication anything was unusual. Flagging it instead gives you the chance to decide: publish it anyway since the delay doesn’t matter much for this particular piece, or hold it and reschedule to a time that makes more sense given the gap that already happened.
Why This Threshold Exists at All
Without some kind of missed-window handling, a scheduler outage would resolve itself in a strange way the moment it came back online: everything that piled up while it was down would potentially fire off in a burst, all publishing within moments of each other regardless of how far past their intended times they’d drifted. The thirty-minute-plus threshold prevents that silent pile-up-then-dump pattern by treating anything that’s drifted that far as needing a fresh decision rather than blindly executing the original, now-stale plan.
What This Looks Like in Practice
- Your scheduler tick stops (a crashed process, a disabled cron job) for, say, forty-five minutes.
- Two items were due to publish during that window.
- Once the tick resumes, it finds both items — but since they’re now more than thirty minutes past their target time, they don’t just auto-publish as if nothing happened.
- Instead, they land in a state requiring a decision, rather than firing off automatically and pretending the delay didn’t occur.
What to Do When You Encounter This
First, figure out why the gap happened in the first place — check whether your scheduler tick is healthy now using the heartbeat approach in “How to Verify Your Scheduler Is Actually Running (Heartbeat Checks).” A one-time blip (a server restart, a temporary network issue) is usually nothing to worry about structurally; a recurring pattern of gaps points to something worth fixing at the infrastructure level — an unsupervised process that keeps crashing, or a cron job that isn’t actually as reliable as it looks.
Second, work through the specific items that got caught in the gap. For most content, simply rescheduling to the next sensible time and moving on is enough — the delay doesn’t meaningfully hurt an evergreen blog post. For anything time-sensitive that lost its relevance because of the delay, this is the moment to make that call explicitly rather than letting it publish automatically into a context it was never meant for.
The Bigger Picture
This threshold is really a safety net for exactly one scenario: your scheduler infrastructure went down for a real stretch of time, not just the normal minute-ish resolution gap. It’s covered in more depth alongside general outage recovery in “Recovering From a Scheduler Outage: What Happens to the Backlog,” and it’s one more reason keeping the every-minute tick reliably alive — through a properly supervised long-running process or a correctly configured cron job — matters more than it might seem at first. The threshold protects you from bad outcomes when the tick fails; it’s not a substitute for making sure the tick doesn’t fail in the first place.
