Disable WP-Cron and Set Up a Real Cron Job in Hostinger hPanel

Every time a visitor hits an uncached page on your WordPress site, core checks if any background tasks are due. If they are, that random visitor gets slapped with an extra 100ms to 300ms of latency while your server processes scheduled jobs in the background. That is default WP-Cron in action. Let’s kill the internal runner and hand the job over to a real, predictable system cron in Hostinger hPanel.

The Problem with Default WP-Cron

WordPress doesn’t run a continuous background daemon. Instead, it relies on a pseudo-cron runner (WP-Cron) that piggybacks on front-end page loads.

On high-traffic sites, this creates nasty race conditions: multiple visitors land on uncached URLs at the exact same second, each firing the exact same scheduled task. On low-traffic sites, you get the opposite problem: scheduled tasks—publishing queued posts, pruning expired transients, firing backups—stall for hours until someone finally wanders onto the site.

Add edge caching (Cloudflare, LiteSpeed Cache, or a CDN) and things break even harder. When visitors only hit edge cache hits, wp-cron.php never fires at all. Offloading these jobs to a real system cron guarantees tasks execute every 5 or 10 minutes like clockwork, without taxing your site visitors.

Step 1: Disable WP-Cron in wp-config.php

First, we need to stop WordPress from checking the cron queue on front-end requests. We do this by declaring the DISABLE_WP_CRON constant inside wp-config.php.

Log in to hPanel, click Manage next to your hosting account, and open the File Manager. Navigate into your site’s root directory (usually public_html).

Right-click wp-config.php, hit Edit, and add this line right above the /* That's all, stop editing! Happy publishing. */ line:

define('DISABLE_WP_CRON', true);

Save your changes. From this point on, user pageviews will no longer trigger background tasks.

Verify WP-Cron is Disabled

Don’t assume it worked—verify it before touching hPanel. You can test your site with a quick curl request from your local terminal:

curl -I https://example.com/wp-cron.php?doing_wp_cron

When default cron is active, visiting your site triggers an asynchronous request to /wp-cron.php that shows up in your server access logs. With DISABLE_WP_CRON enabled, those calls stop. If you have WP-CLI access configured—which we covered in our walkthrough on updating WordPress URLs with WP-CLI—you can verify the constant directly:

wp config get DISABLE_WP_CRON

It should output true. Now that the default trigger is dead, we need a system daemon to take over.

Step 2: Choose Your Execution Method in Hostinger

Under Advanced > Cron Jobs in hPanel, Hostinger provides two primary interfaces: PHP and Custom. Here is how they stack up:

• PHP Binary: Calls the wp-cron.php script directly through the CLI PHP interpreter. This is my preferred approach because it bypasses web server overhead, DNS resolution, and HTTP timeouts entirely.
• Custom (cURL/Wget): Sends an HTTPS GET request to your wp-cron.php URL. It works across any shared setup, but it burns an HTTP connection and is vulnerable to firewall blocks and script timeouts.
• WP-CLI: Executes wp cron event run --due-now over SSH. By far the cleanest method for developers because it streams exact output and error stacks directly to stdout.

For most sites on Hostinger, the PHP binary route strikes the best balance: fast, local, and immune to edge cache rules.

Step 3: Configure the Cron Job in Hostinger hPanel

In hPanel, navigate to Advanced > Cron Jobs from the sidebar menu.

Under Manage Cron Jobs, choose the Custom tab. Do not set this to run every minute—on shared hosting, rapid crons will overlap and eat through your CPU limits. An interval of 10 or 15 minutes is plenty for almost every site.

In the Interval selector, pick Once every 10 minutes or enter the cron syntax manually:

*/10 * * * *

Next, enter the command. If you are using the PHP binary method, check the top-right corner of your hPanel dashboard for your hosting username. Replace u123456789 and example.com with your actual account values:

/usr/bin/php /home/u123456789/domains/example.com/public_html/wp-cron.php >/dev/null 2>&1

Depending on your plan structure, your root directory might live directly at /home/u123456789/public_html/, so verify the file path first. The trailing >/dev/null 2>&1 discards silent output so Hostinger doesn’t send you empty cron notification emails every 10 minutes.

Click Save, and hPanel will register the entry in your server’s crontab.

Alternative: Triggering via cURL

If you’re managing a WordPress Multisite network, using custom subdomains with irregular routing, or using plugins that choke when executed from CLI, hitting the script via HTTP is a safe fallback.

In hPanel’s Cron Jobs screen, set your command to run curl with quiet flags:

curl -s https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Why do we pass ?doing_wp_cron in the query string? WordPress looks for this parameter specifically to bypass the DISABLE_WP_CRON constant. As outlined in the WordPress Plugin Developer Handbook on Cron, supplying that parameter forces WordPress to evaluate and execute due hooks even when front-end cron is disabled in config.

Note: If your site is password-protected or you’re running on a dev environment set up through our WordPress staging workflow on Hostinger, you’ll need to pass HTTP Basic Auth credentials in that cURL command, or the server will return a 401.

The Cleanest Method: Running WP-CLI via Cron

If your Hostinger package has SSH access (toggle it on under Advanced > SSH Access), you can bypass wp-cron.php altogether using the WP-CLI command line tool.

Hostinger includes wp in its global path. Add this command to your hPanel Cron setup:

/usr/local/bin/wp cron event run --due-now --path=/home/u123456789/domains/example.com/public_html >/dev/null 2>&1

This command only executes tasks that are due right now. If the queue is empty, it exits instantly with return code 0, using virtually no CPU.

Gotchas I Hit: Timeouts, Cloudflare, and Overlaps

When I first migrated a WooCommerce shop with roughly 15,000 orders over to a system cron, I hit three issues within the first week. Here’s what went wrong and how I fixed them.

1. Cloudflare WAF Blocked the cURL Requests

If you use the cURL trigger method while running Cloudflare or aggressive bot protections, the WAF will spot the automated traffic hitting /wp-cron.php and trigger a 403 or JS challenge page. The cron fails silently, and no tasks run.

To fix this, create a WAF bypass rule allowing requests from your server’s public IP address targeting the URI /wp-cron.php. Better yet, switch to the PHP binary or WP-CLI approach—both run locally and bypass DNS and web firewalls completely.

2. Script Execution Timeouts on Large Queues

If your site ran without a working cron for a few days, dozens of backlogged hooks will try to process simultaneously on the first trigger. That first run can easily hit Hostinger’s PHP max_execution_time (typically 60 to 120 seconds on shared hosting) and crash mid-execution.

Give the worker extra execution headroom during that initial queue flush by passing inline PHP flags:

/usr/bin/php -d max_execution_time=300 -d memory_limit=512M /home/u123456789/domains/example.com/public_html/wp-cron.php >/dev/null 2>&1

Once the backlog clears, normal runs will finish in under 2 seconds.

3. Memory Leaks from Unoptimized Plugins

Certain backup and reporting plugins execute heavy queries inside cron hooks. If you have persistent object caching enabled—like we set up in our guide on Redis Object Cache on Hostinger—make sure your cron runner has the right Redis extensions available. If your CLI command calls an outdated or misconfigured PHP version, those jobs will fail.

Check which PHP CLI binary you’re using by logging in over SSH and running:

php -v

Make sure this CLI version matches what you picked in hPanel under Advanced > PHP Configuration (for example, PHP 8.2 or 8.3).

Testing and Verifying Your Cron Schedule

Never assume the cron is running just because hPanel saved your job without throwing an error. Check the actual queue.

Install the WP Crontrol plugin from the repository, or inspect the queue over SSH with WP-CLI:

wp cron event list

You’ll see a table listing registered hooks:

+-------------------+---------------------+---------------------+------------+
| hook | next_run_gmt | next_run_relative | recurrence |
+-------------------+---------------------+---------------------+------------+
| wp_version_check | 2026-03-30 14:15:00 | 8 minutes | 12 hours |
| wp_update_plugins | 2026-03-30 14:15:00 | 8 minutes | 12 hours |
| action_scheduler | 2026-03-30 14:10:00 | 3 minutes | 1 minute |
+-------------------+---------------------+---------------------+------------+

Check the next_run_relative column. If you see overdue values like “-2 hours” or “-1 day”, your system cron is failing. Double-check your file path in hPanel, or copy-paste your cron command directly into your SSH terminal to see the raw error output.

You can also force-run a single core hook via WP-CLI to test permissions:

wp cron event run wp_version_check

If everything is working, you’ll see: Success: Executed the cron event 'wp_version_check'.

Frequently Asked Questions

How often should I run the cron job in Hostinger?

Running it every 10 to 15 minutes is ideal for standard sites and blogs. For high-volume WooCommerce stores running inventory syncs, automated billing, or frequent abandoned-cart jobs, bump it to every 5 minutes. Avoid 1-minute intervals on shared hosting plans; overlapping processes will spike your memory and CPU usage.

Will disabling WP-Cron break scheduled posts?

No, as long as your system cron in hPanel is active. In fact, scheduled posts become much more reliable. Instead of hoping an organic visitor lands on your site at 9:00 AM to trigger the publish hook, the system cron guarantees the task fires on time.

Can I use an external cron service instead of hPanel?

Yes. If your hosting package restricts cron execution or you run a headless setup, free monitoring tools like Cron-Job.org can ping https://example.com/wp-cron.php?doing_wp_cron every 10 minutes. Running it locally in hPanel is still better because it avoids round-trips over the public internet.

Why does WP Crontrol show a notice about DISABLE_WP_CRON?

WP Crontrol detects DISABLE_WP_CRON in wp-config.php and lets you know that the core runner is turned off. That notice is expected—it confirms you disabled visitor-triggered execution correctly. As long as your hPanel cron is active, your tasks will process on schedule.

Next Steps for Your Hostinger Stack

With your background tasks running on a predictable system schedule instead of bogging down visitors, check your database for leftover bloat. Stalled cron hooks often leave expired transients piled up in wp_options. If you recently migrated or are setting up a new production environment, check out our guide on migrating a WordPress site to Hostinger without downtime to make sure your database and caching layers are clean.