By default, WordPress doesn’t use a real background daemon for scheduled tasks. Instead, it relies on WP-Cron—a pseudo-cron that checks for pending jobs every time someone loads an uncached page. If nobody visits your site at midnight, your scheduled backups and maintenance tasks stall until morning. Worse, if your site gets hit with a traffic spike, dozens of visitors trigger concurrent PHP requests to wp-cron.php, hammering your server resources. Here’s how to kill the built-in virtual runner and offload everything to a real system cron job in Hostinger hPanel.
Why WP-Cron Fails Under Real Traffic
WP-Cron executes inside the standard PHP lifecycle on uncached page requests. When a visitor lands on your site, WordPress checks if any scheduled event has passed its due date. If it finds one, it spawns an asynchronous HTTP request back to wp-cron.php while serving the page.
This approach breaks down in two common scenarios:
- Low-traffic sites miss deadlines: If no one hits your site at 3:00 AM, your scheduled database cleanups, security scans, or scheduled posts simply sit in the queue until the next visitor arrives hours later.
- High-traffic sites burn server workers: When traffic spikes, multiple requests hit
wp-cron.phpat the same time. This spawns redundant PHP workers, drives up CPU usage, and tanks your Time to First Byte (TTFB).
Throw full-page caching into the mix (like LiteSpeed or Nginx edge caching), and visitors bypass PHP entirely. When that happens, WP-Cron stops firing completely until an admin logs in. Swapping this out for a real Linux cron job gives you reliable, clockwork execution down to the exact minute.
Step 1: Disable WP-Cron in wp-config.php
First, tell WordPress to stop attempting to trigger cron jobs on user visits. You just need to define a single constant in your main config file.
Open wp-config.php in your site’s document root (usually /home/u123456789/domains/yourdomain.com/public_html) using SSH or the hPanel File Manager. Add this line right above /* That's all, stop editing! Happy publishing. */:
/** Disable the default WP-Cron runner */
define('DISABLE_WP_CRON', true);Save the file. If you have SSH access or you’re managing things via terminal as we covered in our guide on how to automate WordPress backups with WP-CLI and Cron on Hostinger, you can quickly verify that the constant is set:
wp config get DISABLE_WP_CRONIf that returns true, WordPress is no longer firing background HTTP requests when users visit your site. Now we need to set up a real server-side runner.
Step 2: Choose Your Execution Method (CLI vs Wget vs PHP)
Hostinger hPanel gives you a built-in Cron Jobs manager. You have three main ways to execute wp-cron.php:
- WP-CLI: The cleanest and most robust option. It runs directly on the CLI without any HTTP overhead, completely bypassing web timeouts and firewall rules.
- Direct PHP execution: Runs
php wp-cron.phpdirectly through the command line binary. Fast, but gives you less visibility into specific tasks. - Wget or cURL: Hits your site over HTTP. It works in a pinch, but it can easily get blocked by security plugins, WAF rules, or Cloudflare challenge pages.
On Hostinger shared and cloud plans, direct PHP execution or WP-CLI is almost always the best pick because neither depends on network availability or HTTP request limits.
Step 3: Create the Cron Job in Hostinger hPanel
Log in to hPanel, select your hosting plan, and follow these steps:
- Go to Advanced > Cron Jobs in the sidebar.
- Set the Type to Custom.
- Paste your execution command into the Command field.
For standard direct PHP execution, grab your absolute path from hPanel. On modern PHP setups (8.2 or 8.3), the command looks like this:
/usr/bin/php /home/u123456789/domains/yourdomain.com/public_html/wp-cron.php >/dev/null 2>&1If your plan includes WP-CLI access, you can run the event runner directly instead:
/usr/local/bin/wp cron event run --due-now --path=/home/u123456789/domains/yourdomain.com/public_html >/dev/null 2>&1The >/dev/null 2>&1 flag at the end discards standard output and error messages so your hosting account doesn’t fill up with massive error log files over time.
Step 4: Set the Correct Timing Interval
Don’t run your cron job every 60 seconds unless you’re running a massive WooCommerce shop with real-time stock syncs. Running cron every minute on shared hosting will burn through your CPU limits and risk getting throttled.
Sensible intervals for most sites:
- Standard blogs and brochure sites: Every 15 minutes (
*/15 * * * *) or 30 minutes (*/30 * * * *). - WooCommerce / E-commerce stores: Every 5 minutes (
*/5 * * * *) to process webhooks and orders without lag. - High-volume publishers: Every 10 minutes (
*/10 * * * *).
In hPanel’s Cron Jobs menu, you can pick a preset like Once per 15 minutes or type standard cron syntax directly into the schedule boxes.
Gotchas and Edge Cases to Avoid
When I first moved a client site to system cron on Hostinger, the tasks looked fine in hPanel but silently stopped running in WordPress. Here are the three main traps to watch out for:
1. Wrong PHP Binary Path
If your account runs PHP 8.3 but the server’s default shell binary points to PHP 7.4, calling plain php in your cron string can trigger an older binary missing required extensions. Check your active PHP version in hPanel or run which php over SSH to verify the exact binary path.
2. HTTP Basic Auth and Staging Sites
If you use wget or curl against a password-protected staging site (like the setups we covered in our guide on how to set up a WordPress staging site in Hostinger hPanel), the HTTP request will fail with a 401 Unauthorized error. Stick to direct CLI execution to bypass web authentication completely.
3. Memory Limits on Large Queues
If your cron queue handles batch email runs, image processing, or large database updates, the CLI worker might run out of memory. You can bump the memory limit inline right in your cron string:
/usr/bin/php -d memory_limit=512M /home/u123456789/domains/yourdomain.com/public_html/wp-cron.php >/dev/null 2>&1Verifying That the System Cron Is Working
After saving your cron job in hPanel, verify that scheduled events are actually clearing from the queue. You can do this via WP-CLI or with a plugin like WP Crontrol.
To check from the terminal over SSH:
wp cron event listCheck the Next Run (GMT) timestamps. If overdue tasks are clearing out and upcoming events reflect the current time, your system cron is working properly. For more details on internal hooks and queue behavior, check the WordPress Developer Plugin Cron Handbook.
If you recently moved your site using our guide on how to migrate a large WordPress site to Hostinger with SSH, make sure to clear out any orphaned cron transients in the wp_options table so old database rows don’t cause duplicate runs.
Frequently Asked Questions
Will disabling WP-Cron break scheduled posts?
No—as long as your hPanel cron job is running. Scheduled posts actually become far more reliable because the system cron fires on a strict schedule regardless of site traffic.
How often should I run cron on Hostinger shared hosting?
Every 10 to 15 minutes is ideal for standard sites. Running it more often than every 5 minutes on entry-level shared plans burns CPU time without giving you much practical benefit.
Can I use an external cron service instead of hPanel?
Yes. Tools like Cron-Job.org or EasyCron can send GET requests to https://yourdomain.com/wp-cron.php?doing_wp_cron. But native hPanel cron is faster, doesn’t depend on outside network stability, and won’t get caught by Cloudflare challenge pages.
What happens if a cron job runs while the previous run is still going?
WordPress uses an internal lock transient (doing_cron). If a cron execution is currently busy, overlapping runs exit immediately until the active lock clears.
Next Steps
With background tasks running on a predictable schedule, your visitors won’t suffer from delayed page loads caused by background PHP workers. If you’re tidying up the rest of your server setup, check out our guide on how to fix SSL mixed content in WordPress with WP-CLI and .htaccess.
