Last updated November 23, 2015. Created on August 19, 2009.
Edited by giorgio79, kasperg, hansrossel, zk_deng. Log in to edit this page.

Various things can keep cron from doing its job on your Drupal site. If your Status report (admin/reports/status) indicates that cron hasn't run recently, try the following to diagnose and fix the problem:

There is a module for that!

Before resorting to code or sql magic, try

Make sure cron.php is being called at all

If your Status report indicates that cron has never run, you may simply need to configure configure a cron job. If you can successfully run cron manually from your Status report screen, Admin menu, or Drush, this is almost certainly the case. If manually running cron fails, you have a deeper problem...

Understand how update.modules permission interacts with cron.php

In 6x, update.modules became part of core. By default, user 1 has permission to run update.module. To expand that permission, you need to grant the user permission to "administer site configurations." You can test this behavior by running cron.php logged out versus logged in as admin. You may find that cron.php is performing correctly even if does not update modules -- check the permissions to see if that is true.

Check for problems with cron itself

If cron hangs, redirects, returns a 404 error, or just plain fails when run manually, you have a problem with cron itself.

  • Cron may be cached badly. Clear your site caches from admin/settings/performance, Admin menu, or Drush, or truncate (empty) all database tables with names beginning with cache_. You could also search for cached instances of cron. To truncate tables using phpMyAdmin, go to the table of interest (beginning with cache_) and select the Operations tab. Click the red Empty the Table (Truncate) in the lower right. If you don't want to do this manually for each cache_ table, you can run:
    TRUNCATE TABLE cache_[table-name];
    TRUNCATE TABLE cache_[table-name];

    etc for each cache_ table you have. The number and names of cache_ tables will depend on your website setup.

  • Cron may have been interrupted during execution, such as by a server restart. This can result in watchdog (error) messages like "Attempting to re-run cron while it is already running" and "Cron has been running for more than an hour and is most likely stuck". Try resetting the semaphore and deleting the "last run" timestamp from the database. (Note: deleting the "last run" timestamp will cause your Status report to indicate that cron has never run.) You can do so with this SQL...
    USE Name_Of_Your_Drupal_Database;
    DELETE FROM variable WHERE name="cron_semaphore";
    DELETE FROM variable WHERE name="cron_last";

    ...or with this PHP in a custom module or script:


    ... or with drush:

    drush vdel cron_semaphore
    drush vdel cron_last
    drush sqlq "DELETE FROM semaphore WHERE name = 'cron';"

    Or with a tiny module:
    If you delete these items from the variable table and still receive the "Attempting to re-run cron while it is already running" error it is probably because those variable values are cached. Follow the instructions above the clear the cache tables and this will likely solve the problem.

  • Cron may be taking too long to complete, resulting in WSOD or in watchdog (error) messages like "Cron run exceeded the time limit and was aborted". All cron jobs of all modules combined should not exceed the 240s timeout limit. This is especially common on sites that have been online for some time where database tables cron is attempting to clean up have become unmanageably large. Check the size of the watchdog, sessions, and accesslog tables and truncate (empty) them if necessary. Check max_execution_time in php.ini.
  • A cron process with too much to do may also easily run out of memory, resulting in PHP error messages like "PHP Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes) in file on line x". Try increasing PHP's memory limit.
  • Semaphore expire value is very old. If clearing cache, truncating watchdog, sessions, and accesslog tables, and deleting cron_semaphore and cron_last from the variables table don't resolve your cron issues, check the expire value in the semaphore table:
    select * from semaphore
    If the expire value is old (convert from unix timestamp to human time) try clearing the semaphore table:
    delete from semaphore;
    and then see if you can run cron.

Check for problems with modules

Certain modules may cause cron to abort, redirect, or return a 404 error. To find an offending module, first find out which ones implement hook_cron. Print a list using this code:

echo theme('item_list', module_implements('cron'));

Disable the modules, one by one, running cron after each one. (At least) the last module you disabled before it starts working again was causing a problem.

Core search module is frequently the source of problems because of errors in nodes it's trying to index. Cron may choke on the following things in your content:

If you know cron is failing during search indexing and you suspect bad content to be to blame, you can use the following SQL to see which nodes haven't been indexed yet—chances are it's choking on one of them.

FROM node n
LEFT JOIN search_dataset d
  ON d.type = 'node'
  AND d.sid = n.nid
  n.status = 1
  AND n.type IN ('blog', 'page')
  AND (d.sid IS NULL OR d.reindex > 0)

Advanced debugging

Debugging option: go into and edit the module_invoke_all function so it looks like this:

  foreach (module_implements($hook) as $module) {
    $function = $module .'_'. $hook;
    if ($hook=='cron'){
        echo "$module  <br />";

That will give you an idea of exactly which cron implementation it's hanging up at, then you can just revert the changes in when you are done troubleshooting.

Debugging with Drush:

find sites/all/modules/ -type f -regex ".*\.\(module\|inc\)" -print | xargs grep "function.*_cron"
drush dis -y <module>
drush cron

Repeat as necessary.

Alternative cron modules,, and offer a more advanced cron which might provide a workaround for hard to solve cron problems.

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


medieval111’s picture

Sometimes "invalid" PHP code in nodes (such as redirects) can stop the cron from running/indexating.
See also: #643474: Invalid PHP code in node, causes whole cron task to crash
And: #286263: Make search indexing smart to handle nodes wth php redirects

I fixed it by adding the following code (from to the top of my PHP code:

foreach(debug_backtrace() as $a) {
  if ($a['function'] == 'drupal_cron_run') {
asiby’s picture

In my case, I did anything I could imagine or find on the internet. The only thing that worked for me was to use php directly instead of wget

0 * * * * /usr/bin/php -q /home/foobar/public_html/cron.php

The output is ugly, but much useful. If you don't need the output,
then redirect it to a black hole (>/dev/null 2>&1)

When doing this, you can make your cron script more secure by setting its permissions to 600 which will prevent running it form the Whole Wild Web anonymously (against DoS attack on your cron.php file).


A. Siby

Live long ... and prosper!

Perfect_Kidkraft_Dollhouses_For_Children’s picture

I’m running Drupal 7.0 on a live site and it’s duplicate development site. Cron stopped running on the live site, but ran perfectly on the dev site.

What was happening is that every time I tried to run it, manually or automatically, it was redirecting to the homepage. I traced it to the drupal_cron_run function but could not figure out why.

I disabled PHP Filter, ran cron (which failed), re-enabled PHP Filter and ran cron again. It now works flawlessly.

tiki16’s picture

Hi where (php file) did you add the code to?

deekayen’s picture

I whipped up a module to help determine if the cron_semaphore variable is set and then to clean it out if desired at

younggeezer’s picture

This may be a "duh" moment for most, but an otherwise working website wouldn't run cron.php under any conditions -- not by wget, not by php command line, not through the admin menu. After a couple of php command-line attempts, I noticed it was complaining about a curl call. I hadn't installed php5-curl -- which after it was installed, cron started working properly. Evidently the feeds package, among others (Paypal WPP?), need it but don't check for it.

ikeigenwijs’s picture

Pete — August 24, 2009 at 03:29.

to fix it surround your redirect code with this:

$semaphore = variable_get('cron_semaphore', FALSE);

if (!$semaphore) {

mennonot’s picture

When I loaded cron.php it was redirecting to a random page in the site and it turned out that was because of php redirect code in another node. Thanks!

konrad1811’s picture

my experience shows that biggest problem is with correct path to php execution and to the script we want to lounch (cron.php)

The thing we need to know is how to checke those correct paths on the server... [works on my private comp - not on commercial internet server]

I've got no idea... Just will try to ask server admin one more time, however they have already told me I type the right path cron didn't work - I gues the admin was just mistaken...

goodghost’s picture

Konrad just read my post about cron and paths. You will solve your problem:

mishott’s picture

this solution really solves problems with cron

cyrus.rezai’s picture

I kept getting this message, and tried deleting cron_semaphore and cron_last, clearing the cache, etc. Non of them worked. But as soon as I run update.php all my problems were resolved. So, try running update.php and see if that solves your problem.

jefferis’s picture

I'm having a bit of a problem and not sure what to do about it. I have a CRON running daily using the cPanel controller and I get a report daily of a successful Cron run, but my admin states, e.g., that a CRON hasn't been run for 2 weeks and 6 days. I try to run a CRON manually within Drupal, but it always stalls and I need to use Cron semaphore to clean it. I followed one advice and went to and it ran through till the page turned white as suggested, but still Drupal Admin does not see it completing. Plus there is no error message. I'm in 6.22 version of Drupal.

Any suggestions appreciated, because I need the CRON to update a sitemap....

jefferis’s picture

I tried the advanced debugging and it produced a fatal error. i replaced the original code in the invoke all command, but I cannot recover the site!!!!!!!!!!!!!!!!!!

This is the error it is not producing! I cannot admin the site. This is terrible:
Warning: Cannot modify header information - headers already sent by (output started at /home/jefferis/public_html/includes/ in /home/jefferis/public_html/includes/ on line 725

Warning: Cannot modify header information - headers already sent by (output started at /home/jefferis/public_html/includes/ in /home/jefferis/public_html/includes/ on line 726

Warning: Cannot modify header information - headers already sent by (output started at /home/jefferis/public_html/includes/ in /home/jefferis/public_html/includes/ on line 727

Warning: Cannot modify header information - headers already sent by (output started at /home/jefferis/public_html/includes/ in /home/jefferis/public_html/includes/ on line 728

Fatal error: Call to undefined function filter_xss() in /home/jefferis/public_html/includes/ on line 655

jefferis’s picture

I uploaded a backup and it fixed it. Something is wonky about the online editor... I guess

avior’s picture

run this sql query
SELECT * FROM `node_revisions` where body like '%drupal_goto%'

look here and change the code like here

gkselvam’s picture

I have drupal commerce shop system with multi-domain module, Product content has been deleted after running drupal cron.

How to debug this one?

Thanks in advance

pokepasa’s picture

Maybe it can help someone.

doomdahdoomdoom’s picture

I have been developing my site for the past couple of months on my local server. I'm ready to launch this weekend - well I thought I was... except that I noticed that cron hasn't run for over two weeks.

I went through this page and tried the suggestions that seemed relevant, but nothing works. It seems likely that it's a content problem, as cron used to run. I'm guessing probably some of the PHP I wrote, by the comments on this page. But removing my PHP doesn't seem to help. It's frustrating that there is no error message at all when I try to run cron manually. Just a redirect to my admin user page.

I was running 7.9 - just updated to 7.12 yesterday. Still same problem... Any ideas?

BigEd’s picture

If you are adding custom php try moving this to a module rather than in page. Look for end statements like DIE or EXIT these will stop the Cron process running.

digitalclover’s picture

I'm currently running into a problem where running cron redirects to the URL "user/0/edit" giving me an Access Denied prompt. I've tried clearing the cache, adding the cron key to the end of the URL, and resetting the cron_semaphore but nothing seems to be working. Any guidance at all would be appreciated.

digitalclover’s picture

I created a page containing some PHP to redirect to the Account Preferences page.


Apparently that was interrupting the cron job. Once I deleted the page, everything worked perfectly.

ghhutch’s picture

My cron job was failing because of a long running backup and migrate module job. Once I disabled this module and re-ran my cron the job finished successfully.

jefferis’s picture

I am really stumped. I have tried every cron script recommended, but I am still getting this error:

Cron maintenance tasks Last run 3 weeks 1 day ago

The problem for me is that I am getting daily reports that cron has been run successfully:

Set-Cookie: SESS7e627b1b0f6dfedc5...8c9b59517db1c3a2; expires=Tue, 31-Jul-2012 08:33:21 GMT; path=/
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Sun, 08 Jul 2012 05:00:01 GMT
Cache-Control: store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Content-Type: text/html; charset=utf-8

So how can the cron run via cPanel but say it is not updating in Drupal 6. 2x? I am having to run semaphore clean every time I try to do it within Drupal manually.

_vid’s picture

It sounds like cron is failing. I would interpret your report page notice "Cron maintenance tasks Last run 3 weeks 1 day ago" to mean 'Last successful cron maint. task run: 3 weeks ago'. i.e. the job is run daily but it is never able to finish. You can confirm this (if you have error logging turned on) by looking in your watchdog report (/admin/reports/dblog) for cron failures.
This is moving into 'forum' territory but if you want to track down the cause of your cron problems you can check out the suggestions in the 'Advanced debugging' section above; updating the file to log which cron implementations are run during the cron task was key for me. The last module listed in your watchdog report right before the cron task fails is the next place to look.
In my case, cron was failing after processing the search module cron implementation. Once I knew that, I disabled the search module and confirmed that cron ran fine. From there I tracked down several 'drupal_goto( )' functions in both 3rd party modules and custom code that were tripping up the search index process.
Fixing those allowed my cron job to run successfully with the search module enabled.
I've posted my workaround for using 'drupal_goto( )' here:
Good luck.

alCHE’s picture

Module Ultimate Cron saved all my problems with Cron

jorisx’s picture

yes can confirm here too

After upgrading a site from D6 to D7 and enabling search cron was failing. when I disabled search cron was running fine
By enabling and setting and setting poormans cron launcher to serial search and cron ran fine again

jorisx’s picture

ok solved it,
some nodes with php code from simplenews broke the search cron
see more:

lemac889’s picture

ghhutch That worked for my!!! Thanks, I disable Backup and Migrate and cron finally worked!!!

wylbur’s picture

I worked through all of these proposed solutions, but found the answer on a different post. To clear the semaphore variable in Drupal 7, use this command in myphpadmin:

DELETE FROM semaphore WHERE name = 'cron';

That cleared the old variable, and cron was able to run.

maxplus’s picture


I did three things:

1. disabled php filter and views php

2. put the site in maintenance mode

3. installed

And I managed to run cron!

I don't know exactly what of the three things did it, but I'm happy it finally worked after 11 months not running Cron on this site...

RaulMuroc’s picture

Installing ultimate_cron module did the trick for me as well.

Drupal Association individual member

Akshita’s picture


This is not the right spot. My apologies. when I created new issue , I don't have any info regarding Cron Version as my module list does not contain Cron as module. Here is my issue. Please do the needful:

Hi ,

Our website is built with openpublic distribution and drupal 7. We are getting weird messages from CRON but the website is running fine and no errors in "Recent log messages" related to cron

Here is the sample message which is bounced as the emaild ID is configured wrong not sure from where it is taking that address


<strong>Subject: Cron <root@vm-abc-uaccdrupal1>   [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete</strong>
Internet Message ID: <20150617150901.89189841E5@vm-abc-uaccdrupal1>
From Address: root@vm-abc-uaccdrupal1
Status: Ready
Size (KB): 2
Message Source Name: SMTP:Default internal receive connector VM-TEST-AB10-EG9
Source IP: ***.**.**.***
SCL: 0
Date Received: 6/17/2015 11:08:57 AM
Expiration Time: 6/19/2015 11:08:57 AM
Last Error: 400 4.4.7 Message delayed
Queue ID: VM-TEST-AB10-EG9\1233434
Recipients:  root@vm-abc-uaccdrupal1;2;2;400 4.4.7 Message delayed;0;CN=EdgeSync - xyz to Internet,CN=Connections,CN=Exchange Routing Group (AAAAAAAAAAAAAAAA),CN=Routing Groups,CN=Exchange Administrative Group (BVBBBBBBBBBBBBB),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,CN={11A1B11F-ABBF-41CD-9EEF-E172C90001FA}


Any help is appreciated.


doublejosh’s picture

Useful query to generate a statement to manually clear your cache tables...

WHERE TABLE_SCHEMA = 'my_database_name'