Last updated March 31, 2015. Created on April 25, 2008.
Edited by joshi.rohit100, aytawn, jweowu, rrfegade. Log in to edit this page.

Setting up cron is an important step in the installation of the website and assists in the maintenance of the site's assets for search results, checking for updates to Drupal core and modules, and removing temporary files.

A properly configured cron job can manage a variety of tasks:

  • The Search module that indexes the website's content.
  • The Aggregator module's that retrieves feeds.
  • The Ping module that notifies other sites of updates.
  • The System module that performs routine maintenance tasks, such as pruning of logs.

What is cron?

Cron is a daemon that executes commands at specified intervals. These commands are called "cron jobs". Cron is available on Unix, Linux and Mac servers. Windows servers use a Scheduled Task to execute commands. The actual "cron job" is a time-triggered action that is usually (and most efficiently) performed by your website's hosting server, but can also be configured by a remote service or even from your own desktop.

What actually happens is that the cron job visits the cron.php file in your website at a URL like You can find the exact address of the cron.php file in the Status report at Administration > Reports > Status report (admin/reports/status) in the section Cron maintenance tasks.

Enabling cron

From Drupal 7 onwards there are two separate ways to run Drupal's cron tasks. The easiest way is to let Drupal do it for you (which it does by default) using its built-in "automated cron" system (which is similar to the "Poor man's cron" contrib module for Drupal 6).

The automated cron system is compatible with all systems because it doesn't actually involve the system's cron daemon. It works by checking at the end of each Drupal request to see when cron last ran and, if it has been too long, processing the cron tasks as part of that request. The two down-sides are (1) cron tasks will only run when Drupal is processing requests; and (2) the 'weight' (processing and memory) of running the cron tasks will be added to some arbitrary unknown page request, which may slow down those requests, and has the potential to exceed memory limits on a complex site.

The second way (which is applicable to any version of Drupal) is to create a cron job, or use some other external (to Drupal) method of triggering its cron tasks, such as an external cron job service like EasyCron or Cronless. This is the more reliable of the two methods (because it will always run on schedule), and it uses fewer resources (because the cron processing is not added to a page request). Therefore this is generally the preferred way to run cron, when you have the choice. Note that if you create a cron job, you may want to disable the "automated cron" system entirely.

In Drupal 8 you can manage the "automated cron" via Manage > Configuration > System > Cron (admin/config/system/cron). The default frequency is every three hours. Cron will then be triggered by end users visiting your site, no more frequently than every three hours. Note that for low-traffic sites it can also be desirable to create a cron job. If you want to disable the automated cron, change the 'Run cron every' drop down to 'never'.

In Drupal 7 you can manage the "automated cron" via the Administration > Configuration > System > Cron (admin/config/system/cron).

In Drupal 6 you need to create a cron job or else use Poormanscron (which works in the same way as "automated cron").

Disabling "automated cron"

For performance reasons, or if you want to ensure that cron can only ever run from an external trigger, it may be desirable to disable the automated cron system.

You can disable it by setting the "Run cron every" value to "Never" (e.g., at Administration > Configuration > System > Cron (admin/config/system/cron)

Alternatively you can set the 'cron_safe_threshold' variable in the {variable} table to 0. (Note that drush will assume this variable is 0 if you have left the "Run cron every" value at the default, so you will need to set it explicitly, either at admin/config/system/cron, or via drush -y vset cron_safe_threshold 0)

Another way to disable cron is to add the following line to your settings.php:
$conf['cron_safe_threshold'] = 0;
Note that this fixes the setting at admin/config/system/cron to "Never", and administrative users cannot override it.


Got Drupal video about cron Drupal 6 that talks about cron, shows various ways of configuring it and helps troubleshooting.

Looking for support? Visit the forums, or join #drupal-support in IRC.


Adam Kowalewski’s picture

I use my Buffalo WHR-HP-G54 with tomato 1.27 firmware to trigger cron on my drupal websites. I made a short tutorial which you can find on my website


drupleg’s picture

Nice tip! I use a WRT54GL with the Tomato firmware, and this is an awesome tip for my local dev site crons, thanks!

a1tsal’s picture

It would be helpful if this page were revised to explain why you might want to use a true, external cron job rather than the "internal" poor man's version (/admin/config/system/cron in Drupal 7).

After spending 15 minutes googling around, it appears that the external cron is "more efficient". How? How much? What functionality has its performance affected?

reg.doug’s picture

The question is not which is "more efficient" because in truth both are equally efficient. The difference is that poormanscron *will* slow down page loads for your end user while "external" cron will not (or at least will mitigate the effect)

Let's consider why this is the case.

First, remember that cron jobs are used to get long tasks done by splitting them into a bunch of short pieces.

When you depend on poormanscron to do your cron jobs for you, it performs one (or a few) of these short jobs every time a user accesses a page on your site. Effectively, this means that to display a page, Drupal has to do more than just render the page in order to finish execution and return some HTML to the end user, which lengthens the page load.

When you use an external cron trigger, it processes the cron tasks in *parallel* with your ongoing page loads so while it may slow down your server because of extra CPU load, it doesn't add to the page load time that your users see.

jweowu’s picture

If you can use a real external cron task, do it.

As the name suggests, the "poor man's cron" approach only makes sense if you can't do it properly.

Not only will requests be slowed down by the added weight of a cron run, but if the cron run happens to be added to a request which is already pushing your memory limits (but would otherwise still be perfectly safe), you could exceed those limits for this completely arbitrary reason.

In general it's a poor alternative to the real thing, so you should disable it if a better option is available.

MRX’s picture

In Drupal 6, looks like there is no cron_key at all. And even guest can come and run cron.php

jweowu’s picture

You want to lock that down in your web server config.

ñull’s picture

.. is very confusing. If I set it to never, when I take that literally, then external cron should not work either. I think the label should be "Visitor triggered cron every...." or similar. I was looking everywhere how to exclusively have external cron and was afraid to set it to "Never" until I tried it and discovered the true meaning. Documentation does not explicitly explain this either.

Wolf_22’s picture

elvin’s picture

Most drupal websites are hosted on shared hosting accounts with cpanel, under which you may find a cron jobs section. Should we set them up there or use dhe internal drupal cron admin page (under drupal 7).

what will work better?

MikeBuzzwoo’s picture

If your server runs 24 hrs a day (which should be the case), then I strongly suggest you use the CPanel cron job functionality instead of the Poor Man's cron. The reasons are given in the other comments:

[talking about Poor Man's cron] Not only will requests be slowed down by the added weight of a cron run, but if the cron run happens to be added to a request which is already pushing your memory limits (but would otherwise still be perfectly safe), you could exceed those limits for this completely arbitrary reason.
In general it's a poor alternative to the real thing, so you should disable it if a better option is available.

chowdah’s picture

I upgraded Drupal 6 to Drupal 7 and did not realize the cron was set up this way by default in Drupal 7, so it was running the poor mans cron in addition to the regular cron I had set up using cpanel on the hosting account when I originally installed Drupal 6.