You set up a Drupal site for a client and after launch, they complain because important things are not happening. Search is not being updated. Backups aren’t being run. Boost is not being cleared. Logs are not being pruned. All these things should run automatically when cron is run (Drupal comes with the ability to run cron automatically) at specified intervals, such as every 3 hours. So when does cron actually run, if not at the specified interval?
Setting cron to run every 3 hours does not necessarily mean that cron will actually run every 3 hours. This is because it is not truly automatic. Something needs to trigger cron to run. This trigger happens when a user visits the site. As part of dealing with the page request, Drupal will check for the last time that cron has been run and will run cron as part of the request if it is time to do so. If cron is set to run every three hours and three hours has passed since the last time it has run, it will run as part of the page request for the user that happens to hit the page at that time.
But what happens if you have an extremely low traffic Drupal site, application or intranet? If no one visits the site at all, cron will not run. Or if a user visits the site and cron is run, and another user visits the site 2 hours and 59 minutes later, cron will not run because three hours hasn’t passed yet. If a third visitor visits 3 hours later, then cron will run. But that is almost 6 hours since the previous cron run.
What about sites with enough traffic?
So on low traffic sites, relying on cron to run automatically is problematic because the times that cron runs will be erratic. What about sites that get more traffic? They should get enough traffic so that cron will run more or less on schedule. But they will face another problem - the time it takes cron to run. Because cron is being run as part of a page request for a real user, it can slow down the page for that user.
Solution: Don’t rely on automatic cron runs
The solution is not to rely on the automatic cron runs. Instead, you can set it up on the server as a cron job. This is not reliant on page requests, so will always run on time. And it will run in the background, so will not slow down page requests for users.
Setting up a cron job using cPanel
If you are using a system like cPanel, or Plesk, setting it a cron job is relatively straight forward. Head to the cPanel account for your site and look for Cron jobs under Advanced.
You will be presented with a page where you can add a new cron job. cPanel comes with some preconfigured settings that you can use. For example, you can select Once per day, and the form will get populated automatically.
You then need to add the Command. This is the URL that will be requested to trigger cron to run. If you look in the root of your Drupal installation, you will see cron.php. The URL hits this file with the addition of a secret key. The secret key is a necessary security precaution to prevent other people from hitting cron.php on your site.
To get the cron URL with your secret key, go to Administration > Configuration > System > Cron. You will see the full URL next to “To run cron from outside the site, go to”
In the Command field in the New Cron job field, add curl --silent followed by the cron URL.
Setting up cron in Linux
If you don't have cPanel, then you can setup cron jobs on the Linux command line. Checkout this great resource for more information: Schedule Tasks on Linux Using Crontab
Disable Drupal’s automatic cron
Now that you have it running on the server level, you can disable Drupal from running the cron. Simply change the Run cron every field to never.
Check that cron is actually running.
Wait until cron should run next. Then go back to the cron config page. If it has run successfully, you will see that the Last run has been updated.
You can also check the log messages, which will confirm that cron has completed.
And that is it! Cron will now run in the background according to the specified timeframes regardless of how much traffic your site gets. And as your site grows and gets more traffic, you don’t need to worry about cron slowing down page requests.