Disable WP-Cron and use real CRON JOB

Use a real cron job instead of the default WordPress WP-Cron (for better performance and reliability).

  • What is WP-Cron, what is it used for, and how to use a Linux server cron job instead.

I promise this is all very easy to do and totally worth your time. It might also fix other random issues you’ve had on your site.

ALWAYS use a real cron job instead of WP-cron.

STEP #1 – disable WP-cron from your wp-config.php file

  • Open up wp-config.php
  • Add define( 'DISABLE_WP_CRON', true); anywhere above the line that says, “That’s all, stop editing! Happy blogging.”

STEP #2 – create a cron job from your webhosting control panel

  • Log into your webhosting control panel (cPanel, etc) and find the Cron Jobs function.
  • Add this line and set it to 5 min intervals wget -q -O - https://domain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1 (change the domain to yours)

NOTES:

  • Some hosts may have limits and force you to use longer intervals (30 mins and up). It’s fine, use the lowest one you can. Even if it’s your own server, I think 5 or 10 mins is frequent enough.
  • If you really need a higher frequency than what your webhost allows, you can either A) get your own server where you have no limits, or B) get a 3rd-party cron service like EasyCron or even Cloudflare workers.
  • Some guides out there use the server directory path (/home/user/public_html/wp-cron.php?doing_wp_cron) instead of the URL. I prefer the domain version as it’s easier to understand and safer (since actual server directory might be different). I think only benefit for server path version is it’s slightly less server work not having DNS lookups and SSL handshake but it’s not noticeable at all.
  • You can use WP Crontrol plugin to manage your cron jobs if you feel they’re backed up or stuck. It’s sometimes an issue for bloated sites. If your cron jobs haven’t run for a while, your site may seem slow or crashed while it catches up. Just wait 5-10 minutes and it should work again.
  • Multi-sites only have to set the cron job for the main site domain. You don’t have to set for each site in there.

You’re done here. Nothing else to do! If if you want to learn more about how cron jobs work, keep reading…

What is a cron job?

A “cron job” is a service built into all Linux servers that runs processes at a scheduled time. (Sometimes called server cron, linux cron, system cron, cron job, “real cron job”.)

These processes are listed in the crontab file on the server. (Usually located in /var/spool/cron for CentOS/RHEL and /var/spool/cron/crontabs/ for Ubuntu/Debian.)

For those curious, the crontab file usually looks like:

0 6 * * * /usr/local/cpanel/scripts/exim_tidydb > /dev/null 2>&1
30 5 * * * /usr/local/cpanel/scripts/optimize_eximstats > /dev/null 2>&1
14 21 * * * /usr/local/cpanel/whostmgr/docroot/cgi/cpaddons_report.pl --notify
32 0 * * * (/usr/local/cpanel/scripts/fix-cpanel-perl; /usr/local/cpanel/scripts/upcp --cron > /dev/null)
0 2 * * * /usr/local/cpanel/bin/backup
35 * * * * /usr/bin/test -x /usr/local/cpanel/bin/tail-check && /usr/local/cpanel/bin/tail-check
5,20,35,50 * * * * /usr/local/cpanel/scripts/eximstats_spam_check 2>&1
/usr/local/cpanel/scripts/update_mailman_cache &&  /usr/local/cpanel/scripts/update_db_cache
25 */2 * * * /usr/local/cpanel/bin/mysqluserstore >/dev/null 2>&1
15 */2 * * * /usr/local/cpanel/bin/dbindex >/dev/null 2>&1
15 */6 * * * /usr/local/cpanel/scripts/autorepair recoverymgmt >/dev/null 2>&1
*/5 * * * * /usr/local/cpanel/scripts/dcpumon-wrapper >/dev/null 2>&1
12,27,42,57 * * * * /usr/local/cpanel/whostmgr/bin/dnsqueue > /dev/null 2>&1
22 22 * * 7 /usr/local/cpanel/scripts/send_api_notifications > /dev/null 2>&1

I know all that looks scary right now but don’t worry! They’re just typical server scheduled server commands that tell it to do maintenance checks and tasks. For example:

  • Running daily backups.
  • Sending out notifications.
  • Deleting mailbox trash that’s older than 30 days.
  • Restarting failed services.

Basically all automated tasks are run by the server cron. It simply checks all the time and runs tasks when they’re scheduled. Most of the tasks you see in there are automatically entered by your server. But you can also add your own (sometimes required for certain plugin functions).

How to read a cron command:

15 */2 * * * /usr/local/cpanel/bin/dbindex >/dev/null 2>&1

  • 15 */2 * * * is the interval part. I would guess this means 15 mins on the hour of every other hour. (e.g. 2:15, 4:15, 6:15)
  • /usr/local/cpanel/bin/dbindex is the command. Basically if you had to type this command manually in CLI everyday, you can now simply make it a cron job and you wouldn’t have to do it anymore. It will run exactly as you type.
  • >/dev/null 2>&1 tells the system to discard any errors or outputs, instead of sending them to an error log or emailing you. Useful since this is only an automated task and nobody is actually at the computer to read it anyway.

And what is WP-Cron?

WP-Cron is PHP function built into WordPress that simulates the server cron service.

It doesn’t actually check the server crontab file every second and run its scheduled tasks. It has its own internal “cron handler” file (not actually a file but stored in database) and only checks it when someone loads up the website. Basically, it’s a fake or pseudo cron service. Or as some developers like to say…”not a real cron job”.

Some scheduled “automated” functions you might find in a typical WordPress site:

  • Comments automatically emailed to commenters.
  • Backup plugin running every night.
  • Scheduled posts publishing live when it’s time.
  • Widgets updating to show the latest data.

How do you think your site “automatically” handles these functions? It does it using the WP-Cron function (which is built into WordPress and runs from the wp-cron.php file). And is triggered every time the website is requested.

This means…every time someone (or a crawler) visits your website…your site runs the wp-cron.php file.

….this can be bad for 2 main reasons:

  1. If your site has MANY VISITS (over 2K/day):
    • It slows down the server needlessly checking the WP cron list multiple times every minute.
    • So a high-traffic site with 500 visitors per second would run 500 WP-cron runs every second, not even including typical bot traffic as well!
  2. If your site has NO VISITS (under 100/day):
    • Your scheduled tasks might not run for long periods. For example if no one (no person or even a bot) visits your site, and you don’t log into the wp-admin area…your backup might not run, etc.
    • The scheduled tasks pile up until the moment you visit and then it runs super slow on that visit since it’s busy offloading all the backed up wp-cron tasks.

In real-world practice, the first issue is more common for me. It’s that high-traffic sites are being slowed down by excessive WP-cron runs. The latter issue of low-traffic sites doesn’t matter much because low-traffic usually means low importance anyway. You should absolutely disable it WP-cron and use your Linux server cron jobs instead if you have more than 100k monthly visitors.

Latest Guides