There are two supported ways to keep the every-minute scheduler tick alive, and neither one is universally “better” — the right choice depends almost entirely on what kind of server you’re running on. This is a practical comparison, not a preference debate, because on some hosting environments only one of the two options is actually available to you.
Option One: A Long-Running Process
The first approach is a single foreground process that stays alive indefinitely and fires the scheduler check every minute on its own internal timer. Its biggest advantage is portability: it behaves identically on Linux, macOS, and Windows, which makes it the simplest mental model if you manage servers across different operating systems and want one consistent approach everywhere.
Its requirement is equally simple: something has to keep that process alive across crashes and reboots, because if the process itself dies, the every-minute tick dies with it — silently, with no OS-level fallback picking it back up. That’s why this approach is almost always paired with a supervisor: a systemd service on Linux, or an NSSM-managed service on Windows, either of which will automatically restart the process if it ever goes down. Left completely unsupervised — just launched from a terminal and forgotten — it’s fragile; a server reboot alone would take it down with nothing to bring it back.
Option Two: OS-Level Cron / Task Scheduler
The second approach delegates the “run every minute” responsibility to the operating system’s own scheduler — cron on Linux/macOS, Task Scheduler on Windows — which triggers a quick, one-off check every minute and lets the process exit immediately afterward. Nothing has to stay alive between ticks, because there’s nothing running between ticks; the OS itself is what remembers to fire it again next minute.
This is the lighter-weight option, and critically, it’s the only option on shared hosting environments like Hostinger, which actively terminate long-running background processes. If you’re on shared hosting, this isn’t really a choice between two options — cron is the only one available. See “Setting Up the Laravel Scheduler on Shared Hosting (Cron-Only)” and “Handling Hostinger’s Long-Running-Process Limits With Cron Jobs” for that specific setup.
Side-by-Side Comparison
- Portability: the long-running process wins — identical setup and behavior across operating systems. Cron/Task Scheduler configuration differs meaningfully between Linux and Windows.
- Shared hosting compatibility: cron wins outright — it’s the only option that works there at all.
- Resilience to crashes: roughly even, but for different reasons. The long-running process needs a supervisor (systemd/NSSM) to auto-restart it; cron needs nothing extra since the OS itself re-triggers every minute regardless of what happened last time.
- Setup complexity: cron is simpler to configure initially (one line in a crontab, or one hPanel entry) but the long-running process, once wrapped in a supervisor, requires effectively zero day-to-day attention.
- Visibility: a supervised long-running process gives you a service you can query directly (systemd status, for instance) for its current state; cron jobs are more opaque unless you’re actively checking logs or a heartbeat.
Recommendations by Environment
On a Linux server or VPS you control: the long-running process wrapped in a systemd service is generally the more robust default — it restarts automatically on crash, and systemd gives you a clean way to check its status at any time. Cron calling the one-off check is a completely valid alternative, and honestly simpler if you’d rather not manage a service file at all.
On shared hosting: cron is your only real option, and it works fine — it’s exactly what shared hosting is designed to support, and one entry running once a minute is enough to drive scheduled posts, the Auto Scheduler, and workflows together.
On Windows: the long-running process via Task Scheduler (configured to run at startup and restart on failure) or an NSSM-managed service both work well; Task Scheduler calling the one-off check on a repeating trigger is the closer analog to Linux cron if you prefer that model.
“Systemd vs Task Scheduler: Keeping Your Scheduler Alive on Any OS” goes deeper on the supervised long-running-process route specifically, and “Comparing schedule:work Uptime Against Traditional Cron” looks at reliability characteristics of each in more detail.
The One Thing That Doesn't Change
Whichever option you choose, the end result is identical: an every-minute check that discovers due queue items, workflow steps, and optimizer tasks and fires them. Neither approach changes what gets published or when — they’re two different delivery mechanisms for the exact same tick. That’s worth remembering if you ever migrate hosting environments: switching from a long-running process to cron (or vice versa) is purely an infrastructure change. Your queue, your Auto Scheduler defaults, your workflows, and your Content Calendar don’t need to know or care which one is firing the tick underneath them, as long as one of them reliably is.
