When you schedule a post for later rather than publishing it immediately, something has to actually notice when the target time arrives and push it live. That something is a background check that runs once every minute, and understanding how it works clears up almost every question people have about scheduled posting — why it isn’t instant like ASAP, why it can be up to a minute later than the exact time you picked, and what “the scheduler” even refers to when someone tells you it’s down.
The Core Mechanism
Underneath the scheduling features sits a job that ticks every single minute and asks, in effect, “is anything due right now?” It checks the queue for items whose scheduled time has arrived and haven’t been published yet, and for each one it finds, it publishes it — right there, as part of that same minute’s check. There’s no separate hand-off to another process waiting in line; the publish happens inline, during the tick that discovered the item was due.
Alongside that queue check, two sibling jobs run on their own schedules: one that advances multi-step workflows every five minutes, and one that handles scheduled optimizer tasks every minute. All three depend on the same underlying trigger — the scheduler being alive and ticking — which is why “is my scheduler running” is really one question with implications for three different features at once, not three separate things to check.
Why Once a Minute, Not Instantly
This is the detail that surprises people coming from tools that feel instantaneous: a post scheduled for 9:00 a.m. might actually go out at 9:00:47, or 9:01:02, depending on exactly when within that minute the check happens to run. That’s an intentional tradeoff, not a bug — checking every single second would be wasteful for something that doesn’t need second-level precision, and a one-minute resolution is more than tight enough for blog scheduling. If you need something to go out at an exact instant with zero delay, that’s what “Add to Queue → ASAP” is for (covered in “Why ‘Add to Queue → ASAP’ Publishes Instantly, No Scheduler Needed”) — it publishes synchronously in the request itself, with no minute-boundary rounding at all.
No Separate Queue Worker Required
A detail that trips up anyone who’s run a Laravel application before: normally, background jobs get dispatched to a queue and a separate worker process has to be running to actually pick them up and execute them — miss that worker and jobs pile up untouched. That’s not the case here. The queue connection is configured to run jobs inline (synchronously) rather than dispatching them to a separate worker, so the every-minute scheduler tick both discovers due items and publishes them in the same step. That means one process to keep alive — the scheduler tick — rather than two. We go deeper on this specific point in “Why QUEUE_CONNECTION=sync Means You Don’t Need a Queue Worker.” If you ever do switch to a different queue backend, that changes — you’d need a worker running alongside the scheduler — but out of the box, it’s a single moving part.
What Keeps the Tick Alive
The every-minute check itself has to be triggered by something external, and there are two supported ways to do that: a single long-running process that fires the check on its own timer, or the operating system’s own scheduler (cron on Linux/macOS, Task Scheduler on Windows) triggering a one-off run every minute. Which one applies to you depends on your hosting environment — shared hosts like Hostinger only support the cron-style approach, since they terminate long-running background processes automatically. “schedule:work vs OS Cron: Picking the Right Approach for Your Server” walks through choosing between the two, and “Setting Up the Laravel Scheduler on Shared Hosting (Cron-Only)” covers the shared-hosting case specifically.
Tracing a Scheduled Post's Life
Here’s the full path a scheduled post takes, end to end:
- You add it to the queue with a target time, and it’s marked “waiting.”
- The every-minute check runs, sees the current time hasn’t reached the target yet, and does nothing — it stays “waiting.”
- On the tick where the current time reaches or passes the target, the check picks it up and publishes it inline.
- Assuming publishing succeeds, the status flips to “posted,” and it becomes visible in the Content Calendar as a clickable, published entry.
- If something goes wrong during that process — or the underlying job runs long enough to hit its time limit — the item is marked “failed” with a specific reason, rather than sitting ambiguously.
That last point matters more than it might seem: a fix now ensures that jobs which time out mid-generation get flipped to a clear failed state automatically, instead of getting stuck showing “processing” forever with no resolution. See “Diagnosing a Post That’s Stuck in ‘Processing’ Forever” and “Monitoring Job Timeouts: The 300-Second Limit and What It Means” for the specifics.
What "the Scheduler Is Down" Actually Means
Because the every-minute tick is the single trigger for scheduled posts, the Auto Scheduler, and the workflow engine, “the scheduler stopped running” has a very specific, checkable meaning: the process or cron job responsible for firing that tick isn’t executing anymore. That could be a crashed long-running process on Linux, a shared-hosting cron job that got disabled, or a Windows Task Scheduler entry that silently failed. Whatever the cause, the symptom is the same across every feature that depends on it — items pile up in “waiting” well past their due time, and nothing new gets published automatically. “How to Verify Your Scheduler Is Actually Running (Heartbeat Checks)” covers exactly how to confirm the tick is alive without guessing, and it’s worth checking any time scheduled posts seem to be lagging behind their target times by more than a minute or two.
Understanding this one mechanism — a check every sixty seconds, publishing inline, no separate worker — demystifies most of what looks like “magic” in the scheduling system. It’s a simple loop doing a simple job, reliably, once a minute.
