Cron jobs not working

Cron jobs are not running on my website – so my Snapshots are not running and also any other Cron jobs.

I checked with my hosting company and wp-cron is running but it is not running any of the cron jobs.

I have the Crontrol plugin installed and it indicates that the jobs have not run since June. It was at that time I had installed the Heartbeat Control plugin and it screwed up my site.

I did not realize it was not multisite compatible. I did disable and delete the plugin, but I don’t know how to fix this cron issue.

  • Adam Czajczyk
    • Support Gorilla

    Hello joan_donogh

    I hope you’re well today and thank you for your question!

    I’ve checked your site and it seems that something on the site is blocking Cron calls. Initially, the site was configured via an additional define line in “wp-config.php” to lockout cron jobs for 10 minutes everytime (which is more than default shortest cron schedule = 5min). Additionally, there was an attempt to run a server cron job but the internal WP Cron was not disabled.

    This together could be causing issues (though it shouldn’t) but further check showed that there’s something more into it. When I set all cron configuration to default (so WP Cron, no server cron, standard cron timeout), no schedules were run. However, switching to “ALTERNATE_WP_CRON” did work so the cron procedures themselves are working.

    It also worked when I called cron URL (the same that used in server cron configuration) manually via browser.

    The ALTERNATE_WP_CRON is not the best solution as it’s an additional redirect in user browser and is also depending heavily on the traffic so I only used it for testing. The server cron though doesn’t seem to be executed at all.

    The heartbeat plugin shouldn’t cause that by the way, because after removing it the changes it makes are also removed so even if it interfered it should all get back to normal after it’s disabled.

    That being said, I’ll need some helping hand from our developers on this. I’ve already passed my findings to them so please keep an eye on this ticket and we’ll update you here as soon as we get to know more from them.

    Best regards,


  • joan_donogh
    • Site Builder, Child of Zeus

    Hi Adam, thank you very much for your reply! The issues you mentioned were added by the support guy at SiteGround. Originally they told me it was “not their problem” and that I had to pay someone on Codeable to fix it. (which is when I contacted you) I sent them a link to a similar issue from the Crontol plugin where the developer said it was a server issue , and then they decided to help me!

    This is what he said he did:

    I have reviewed your case in great detail and it appears that the cron jobs are indeed not executing properly and all cron tasks were showing as pending.

    To clear out any pending cron jobs, I force-ran all crons through the wp-cli command line tool and their execution was successful: (code)

    After that I ran another check and the crons showed as successfully ran with next executions already scheduled: (code)

    However the triggering still did not happen even with cron executions, so I went ahead and set a delay for the internal cron jobs to once every 10 minutes, as per this article.

    After that I set a real cron job to run every 5 minutes, as this is the smallest recurrence of any cron tasks – the one for snapshot_remote_file_cron.

    The cron job is set as per our article in the cPanel -> Cron Jobs menu.

    After that I monitored the cron tasks for about 20 minutes and they were properly executed on schedule from the system cron, please verify on your end as well.

    But now all the cron jobs are getting stuck at (now) again. I am concerned because there are almost 600,000 session records in my options table, because the cron job to clear them has not been working.

  • Adam Czajczyk
    • Support Gorilla

    Hi joan_donogh

    Thank you for your response, that was very helpful and helped me fix the site :slight_smile:

    As for the response from your host that you quote.

    I can confirm that this is exactly how it was set and that I found out about exactly the same behavior. I believe though that there’s one thing they overlooked. They wrote “After that I monitored the cron tasks for about 20 minutes and they were properly executed on schedule from the system cron” and that got me thinking. I believe they confirmed that cron itself was executed but didn’t check whether the tasks on site are indeed triggered by it.

    When I was checking the site yesterday I came to the conclusion that the server cron is not actually triggered. But after reading this I checked the server again and looked into cron stats et voila, it turned out that cron schedule was actually running fine on a server.

    Now, the cron on server is supposed to trigger a specific command. It’s triggering a “wget” command which is a way to fetch a specific URL. The URL that it was supposed to be fetched was working itself – I checked that yesterday by calling it manually via browser. So, that got me to a conclusion that there’s something wrong with a way “wget()” is fetching it. Unfortunately, I don’t have that much insight into server to be able to find out what exactly is happening but apparently either the wget() command is not working at all or for some reason connection from server to the site over wget() is rejected. Hard to say.

    Anyway, knowing that I set the same server-side CRON job but using a different way to fetch CRON URL: using curl library – that’s pretty much the same as calling URL via browser, just server-side and automated. You can see how it’s configured if you check cron jobs in cPanel.

    It worked. I watched cron tasks execution in WP Crontrol plugin for a great amount of time and after a while all the “overdue” tasks got cleared up and now all the tasks are rotating properly. The “wp_session_garbage_collection” event also cleared up some of these “_wp_session…” rows from the database and they are now kept on a reasonable level.

    As for these sessions. By default WordPress is not storing such data and the “wp_session_garbage_collection” is not a core WP cron event either. I was dealing with a similar issue recently related to the MapPress google maps plugin which apparently had some broken cron/session handling routines but the plugin is inactive on your site (unless I missed something).

    The other plugin that can cause this is WP Session Manager. I checked the site and in this case that’s a WP Session Manager included as a part of the Awesome Support plugin that you got installed and active on site. So that’s exactly what’s “generating” all that “_wp_session….” data. The fact that there was almost 600k of these rows in the database wasn’t actually a reason of the CRON issues but a consequence of them – the “wp_session_garbage_collection” event was not triggered, hence these sessions were not removed from database.

    So, sorting the CRON issue actually sorted out the “side issue” as well :slight_smile: Such an amount of data in “wp_options” table makes the “wp_options” table very big (it was over 40M of size) which in turn can actually slow down the site.

    To sum it up: I think this was after all server related issue but the current cron configuration seems to be working fine, as expected. “Sessions” in the database are under control now either so I think it should be good now :slight_smile:

    Best regards,


  • joan_donogh
    • Site Builder, Child of Zeus

    Adam, you are amazing! Thank you so much!! I thought something was up when I opened my email this morning and I had an email reply through the Awesome Support system. (Which wasn’t working before because the cron job that was supposed to check the email account and pipe the emails into the support system wasn’t working. This was the reason I discovered the cron jobs weren’t running.) I have checked in the Crontrol settings and everything still seems to be running fine!

    Now hopefully my Snapshot backups will start running again too.

    Mappress is active on one of my demo sites in the network, but yes I am sure that most of the sessions are coming from Awesome Support. I didn’t know what was generating those sessions, I thought maybe it was just a regular WordPress thing. But, yes, I was quite worried that the options table was going to slow down the site if it was going to keep growing with cron not running to clear it out.

    Thanks again so much for getting to the bottom of this!


Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.