Hostinger and similar shared hosting plans are a common, affordable choice for running a WordPress site, and they come with a real constraint that catches people off guard the first time they try to set up continuous background automation: no long-running processes.
What "No Long-Running Processes" Actually Means
Shared hosting environments are built around handling many customers’ short-lived web requests efficiently, not hosting a process that’s supposed to stay alive indefinitely in the background. A script meant to run continuously — the kind of persistent worker process `schedule:work` normally is — gets killed by the hosting environment, sometimes without an obvious error message pointing to why.
Why This Breaks the "Normal" Laravel Scheduling Approach
Laravel’s conventional scheduling setup assumes `schedule:work` runs continuously, checking every minute for due jobs from inside its own persistent process. On hosting that won’t allow a persistent process, this approach simply doesn’t work — not because of a configuration mistake, but because the underlying assumption (a process that stays alive) doesn’t hold on that infrastructure.
The Cron-Only Alternative
The workaround is using the hosting platform’s own cron job scheduler — a feature virtually all shared hosts including Hostinger provide — to trigger Laravel’s scheduler check once a minute from outside the application, rather than relying on a Laravel process to stay running and check internally. Each cron trigger runs, checks for due work, executes it if any exists, and exits — no persistent process required.
Setting This Up in Practice
This means configuring a cron job in the hosting control panel (typically cPanel or hPanel on Hostinger) to call `php artisan schedule:run` once every minute, rather than trying to keep `schedule:work` alive as a background service the hosting environment won’t sustain. This is a one-time setup step, and once in place it behaves functionally the same as the persistent-process approach from the site’s perspective.
Verifying the Cron Job Is Actually Firing
A misconfigured cron job fails silently from the outside — nothing publishes, and there’s no obvious error to point at. Checking the scheduler’s heartbeat status after setup confirms the cron trigger is actually reaching the application on schedule, rather than assuming setup succeeded just because no error appeared.
Trade-Offs Compared to a Persistent Worker
Cron-triggered scheduling checks in at fixed intervals rather than continuously, which introduces a small, generally inconsequential delay (up to the length of the interval) between when a post is technically due and when it actually gets picked up. For once-a-minute cron, this delay is negligible for virtually every practical publishing use case.
Where to Go Next
For the complete comparison between this approach and the alternatives, see the complete guide to scheduling and workflow automation.
