What Is Cron?
In simple terms, cron is a job scheduler in unix-like operating systems. It is also called as system cron or OS cron especially if the discussion is also about WP Cron. The job can be anything that needs to be done at a particular time. The job could be an one-time job (such as launching a rocket at a scheduled time) or repetitive (such as turning the lights on upon sunset and turning them off upon sunrise, every day!). Basically, the system cron is a program that runs all the time just to trigger a particular action at a particular time. You can throw hundreds of tasks on it to do at various intervals. System cron is like robot who is always available at your service!
What is WP Cron?
WP Cron helps to do the following tasks (among others) in WordPress core…
- Publishing scheduled posts
- Checking for updates to WordPress core, plugins and themes
- Applying updates (depending on the configuration)
Plugins can also utilise WP Cron to do various tasks…
- Pulling the latest social media tweets to display on the site
- Sending small batches of newsletters if your site has thousands of subscribers
- Updating inventory based on external resources
WP Cron is like an on-call assistant. It means it doesn’t run jobs all the time. It runs jobs only when someone visits your site!
WP Cron was introduced because of the limitations on the hosts (such as shared hosts) where hosts don’t allow access to the system cron. At the same time, it was never meant to replace the system cron that is more precise in executing the tasks on time. WP Cron is meant to make sure that the tasks are done irrespective of when they are done. That’s the basic difference between the system cron and WP Cron.
The other is… WP Cron can only run with a minimum frequency of 5 minutes. The (OS) cron can run at a frequency of 1 minute. Also, using a system cron can help us to run any script. WP Cron is less flexible in this regards.
What’s the problem with WP-cron?
The advent of full page caching engines, such as WP Super Cache, prevented visitors hitting the WordPress (to be precise the PHP). Full page caching engines generate HTML files that can be served directly, if exists. With the recent development on preloading full page cache, it becomes even easier to generate cached version of a blog post immediately after it is published.
This is actually good news for everyone. It saves the precise server resources for host. It saves a few bucks too. It makes delivering content much faster, without having to process PHP and MySQL. But… it isn’t good news for WP Cron. WP Cron runs only when a visitors hits uncached version of the site, thus triggering PHP, MySQL and WordPress in turn. The result is too many WP cron tasks accumulated over a period of days, weeks or months, depending on how fierce your full-page caching engine is. At times, you may see thousands of cron jobs that just fill the database, reducing the overall performance of the backend.
Most common problem with WP Cron is that scheduled posts are not published on time. Again, it is due to aggressive caching system or lack of any visitors to the site. If you run a multisite, the problems are even bigger.
What’s the solution?
Simple. Let system cron trigger WP-Cron!
If your host doesn’t support (system) cron or if you want more features than what’s offered by your webhost, then head over to easycron.com, setcronjob.com or any similar external cron service. They support per minute cron jobs, notifications upon failures, offer logging to name a few.
Most managed WordPress hosts have built-in cron system to trigger WP Cron regularly. cPanel supports cron too. Even some regular generic web hosts support OS cron.
If your host supports cron, do yourself a favour by hiring a developer to setup the cron for you!