`schedule:work` and traditional OS cron both get scheduled jobs running, but they’re not equally reliable in every hosting context, and comparing their actual uptime characteristics matters more than comparing their setup convenience once a site depends on consistent publishing.
How schedule:work Behaves When It's Supported
`schedule:work` runs as a persistent process, continuously checking for due jobs without the overhead of restarting a fresh process every minute the way cron-triggered execution does. On hosting that genuinely supports long-running processes, this tends to produce very tight, consistent timing — the check genuinely happens close to every minute, without cron’s inherent one-minute-resolution scheduling granularity.
Where schedule:work's Uptime Risk Actually Comes From
The risk isn’t the approach itself — it’s that a persistent process can be killed by the hosting environment (a deploy, a server restart, a resource limit) and, unlike cron, doesn’t automatically restart on its own unless something else is specifically watching and reviving it. A `schedule:work` process that dies silently at 2am can sit dead for hours before anyone notices, since nothing inherently checks that it’s still alive.
How Cron's Reliability Profile Differs
Cron doesn’t have a persistent process to die — each trigger is a fresh, independent invocation managed entirely by the hosting platform’s own cron infrastructure, which is generally very reliable at actually firing on schedule. The trade-off is the one-minute (or coarser) granularity and the overhead of a fresh process start each time, rather than a continuously warm one.
Why Cron Tends to Win on Uptime for Most Real Sites
For the specific case of a scheduler that needs to reliably fire roughly once a minute over long stretches of time without manual babysitting, cron’s lack of a persistent process to fail is usually the more resilient choice in practice — there’s no single long-lived process whose death silently stops everything until someone notices.
Where schedule:work Still Makes Sense
On infrastructure that genuinely supports and monitors persistent processes properly — a VPS or dedicated server with process supervision (systemd, for instance, restarting the process automatically if it dies) — `schedule:work`’s tighter timing and lower per-check overhead becomes the better trade, since the “process dies silently” risk is mitigated by the supervision layer.
The Practical Recommendation for Most Setups
For shared or budget hosting without real process supervision available, cron-triggered scheduling is generally the more reliable default despite its coarser timing granularity; for infrastructure with proper process monitoring, `schedule:work` becomes worth the added setup complexity for its tighter execution timing.
Where to Go Next
For the complete comparison of scheduling infrastructure options, see the complete guide to scheduling and workflow automation.
