Shared hosting is the most common place people run into scheduling problems, and it’s also the place where the fix is simplest once you know the one rule: on shared hosting, you cannot run a long-lived background process, so you must use a cron job instead. This piece walks through exactly how to set that up so scheduled posts, the Auto Scheduler, and workflows all keep firing on time.
Why Shared Hosting Is Different
The scheduling system needs something ticking every minute to notice due items and publish them. On a server you fully control, that “something” can be a single process that just stays running in the background indefinitely, checking the time every sixty seconds forever. Shared hosting environments — Hostinger’s shared plans among them — don’t allow that. They actively kill long-running background processes as a matter of policy, because one tenant’s forever-running script would otherwise eat resources shared across many accounts on the same box. So the long-running-process approach simply isn’t available there, no matter how you try to configure it.
The alternative isn’t a downgrade, though — it’s the other officially supported path: let the host’s own cron system fire a quick, one-off check every minute instead of running one continuous process. Cron jobs are short-lived by design (they start, run, and exit), which is exactly the shape shared hosts are built to support.
Setting It Up on Hostinger
The setup lives in hPanel, under Advanced → Cron Jobs:
- Set the interval to run every minute — choose “Custom” and enter the standard five-field cron pattern for “every minute.”
- Point the command at your PHP binary and your application’s
artisanfile, running theschedule:runcommand. You’ll need the exact absolute path to both — find them in hPanel → Files. - Double-check which PHP version is actually active in hPanel → PHP Configuration. Hostinger often exposes version-specific PHP binaries at paths that look different from the generic system PHP, so use the matching path rather than assuming a default.
artisanitself typically lives one directory abovepublic_htmlon Hostinger, not inside it — point the command at wherever your application root actually is, not at the web-facing folder.
Once saved, give it a minute and confirm it’s actually firing — either via the heartbeat indicator on the Auto Scheduler page, or by checking the application’s log file for a fresh entry from a scheduler run. “How to Verify Your Scheduler Is Actually Running (Heartbeat Checks)” covers both methods in detail.
One Cron Entry Handles Everything
A common worry is that you’ll need multiple cron entries — one for scheduled posts, another for the Auto Scheduler, another for workflows. You don’t. Because jobs run inline rather than through a separate queue worker, that single cron entry calling schedule:run once a minute is enough to drive scheduled posts, the Auto Scheduler, and the workflow engine all at once. There’s no additional worker process to configure alongside it on a default setup. See “Why QUEUE_CONNECTION=sync Means You Don’t Need a Queue Worker” for why that’s the case.
Common Mistakes on Shared Hosting
A few things reliably go wrong the first time people set this up:
- Wrong PHP binary path. Using a generic
phpreference that doesn’t point at the version your app actually needs will either fail silently or throw version-mismatch errors buried in a log nobody checks. - Pointing at the wrong directory. Running the command from inside
public_htmlwhenartisanactually lives a level above it means the command can’t find the file at all. - Assuming it’s working because it was saved. Saving a cron job in hPanel doesn’t guarantee it’s actually executing correctly — always confirm with a real heartbeat check or a fresh log entry rather than trusting the interface alone.
- Trying to run a long-lived process anyway. Some people try to work around the shared-hosting limitation by launching a persistent background script through a one-off SSH session or a startup script. It’ll get killed. Don’t fight the hosting model — use the cron path, which is fully supported and designed for exactly this situation.
What Happens If the Cron Job Stops
If the cron job gets disabled, deleted, or silently stops firing — which can happen after a hosting migration, a plan change, or an accidental edit in hPanel — the symptom is consistent: scheduled items pile up in “waiting” status well past their intended time, and nothing publishes automatically. Nothing is lost — items sit safely queued — but they won’t move until the cron job is restored. “Building a Failsafe: What to Do When the Cron Job Silently Stops” and “Recovering From a Scheduler Outage: What Happens to the Backlog” cover how to catch this quickly and what happens to items that piled up while it was down.
When You Outgrow Shared Hosting
If you eventually move to a VPS or a server you manage directly, you gain the option of running a genuine long-lived process instead of relying purely on cron — typically wrapped in a systemd service so it restarts automatically if it ever crashes. That’s a nice-to-have, not a requirement; cron-only setups on shared hosting work perfectly well for scheduling. See “schedule:work vs OS Cron: Picking the Right Approach for Your Server” and “Systemd vs Task Scheduler: Keeping Your Scheduler Alive on Any OS” if and when you make that move. Until then, one correctly configured every-minute cron job pointed at the right PHP binary and the right artisan path is everything the scheduling system needs to run reliably on shared hosting.
