Imagine a team of thieves who are set to rob a bank. They’ve hired a driver to pick them up at an appointed time. The exact time that they’ll walk out of the bank.
They then enter the bank and have set their stopwatch. They have 180 seconds to get everything they can and walk back out – in order to beat the cops to the bank. And in 180 seconds (three minutes), their driver will drive up and pick them up.
In a situation like that, if you’re one of the bank robbers, you want to make sure that everything goes according to plan, right?
But what if I told you that the driver’s watch worked differently than other watches? What if I told you that his second hand moved only when he was on his cell phone? Or only when he moved his arm? Or only when he smoked a cigar?
Not a very reliable watch, right? And if that’s not reliable, could you count on him to come get you at the right time?
I didn’t think so.
Let’s talk about WP-Cron
We’ll get back to our bank robbers in a just a second. But first let’s cover what Cron is.
It’s actually the name of a command from the old Unix days where you could schedule a future event to happen at a specific time. That’s pretty handy, right? Imagine you wrote some logic but you only wanted it to happen at midnight. Then you’d put that code in a spot and only call it every night at midnight, using Cron.
So you can then imagine that WP-Cron is like that. And it is. Except where it’s different.
WP-Cron is Cron for WordPress. And here’s the thing – every server that runs WordPress is different. So that means that implementing a low-level set of commands that will work on any and every environment is pretty darn tough.
So WP-Cron doesn’t work that way. It’s not based on the server, or the server’s clock.
Instead, there’s a check every time a person calls one of your pages or posts. Every time WordPress goes to work, it checks to see if there are any jobs that need to leverage WP-Cron.
But that’s a bit precarious, as you might imagine. Especially for sites that don’t get hit very often.
In other worlds, WP-Cron works fine for sites that get a decent amount of attention, but not necessarily as great for those sites with little to no traffic.
In this way, WP-Cron is like having a driver with a watch whose time is dependent on something other than the normal second passing. Instead, it’s tied to a variable (like arm movement). In your case, the variable is a request (as in a call to a post or page).
So is WP-Cron great for large sites?
Since I told you it wasn’t great for small sites, you’re likely thinking that it’s awesome for large sites because they’re always getting traffic. And that would mean that processes would get called any and all the time.
That is true. But that is also its potential issue on highly trafficked sites. Because every request can spawn a process that goes to work and takes up server resources. Imagine spinning up several (a lot) of server processes all concurrently. That might easily bring your server down if you don’t have adequate resources.
So in the end, I don’t like WP-Cron for small sites. And I don’t like it very much for large sites.
I prefer a regular cron job. Something that’s scheduled using a normal clock.
Here’s what I use instead of WP-Cron
A few years ago we decided to make some nightly routines in our real estate solutions that use WordPress. And that’s when we decided to move from WP-Cron to something else. Our something else is called SetCronJob – and it’s an online service.
The service works regardless of what kind of server I’m hosting with, which is helpful for us. It also is really easy to schedule and control. And lastly, it’s inexpensive (and free for some folks).
We’ve been using an externalized cron service now for 30 months and have absolutely loved the simplicity and consistency of the service.
Because, if you’re going to rob a bank, or do anything even more important, you want the guy who’s helping you to have a watch that works – all the time, every time.
And that means I need an external cron service like SetCronJob. Check it out!