In WP Crontrol version 1.16.2 a security hardening feature was added which prevents the code in a PHP cron event from being tampered with. You can read about the feature here.

If you have PHP cron events in place prior to upgrading to this version then you will need to re-save your PHP cron events so the required security hash can be generated and stored alongside the PHP code and the events can continue functioning.

If you don't have any PHP cron events in place on your site then you don't need to do anything.

What do I need to do? ​

1. Visit the Tools → Cron Events screen in the admin area of your site
2. Click the "PHP events" filter at the top of the list

If you don't have any PHP cron events on your site then this filter won't appear. You don't need to do anything further as your site is unaffected by this change.

If you do have PHP cron events in place on your site:

4. Click the "Check and edit" link below each event that shows a "Needs checking" message
5. Confirm that the PHP code in the event is as expected
6. Click the "Update Event" button

Repeat this for any further PHP cron events that show a "Needs checking" message.

Will I need to do this again? ​

This is a one-off action that's required after updating to version 1.16.2 or later from a prior version.

What if I no longer need one of the affected events? ​

You can delete an unwanted event by clicking the "Delete" link below the event.

What if I don't have permission to edit a PHP cron event? ​

See here for full information about PHP cron events. You'll need to temporarily enable the ability to edit PHP cron events in order to save the affected events.

What if the "Needs checking" message appears again? ​

If WP Crontrol is showing you a message saying one or more of your PHP cron events need to be checked and you haven't just updated WP Crontrol from a version prior to 1.16.2, then it could either mean there is a real problem caused by tampering of the PHP code in the events, or it could be caused by your security salts having been changed.

If the PHP code in an event has been tampered with externally then WP Crontrol will refuse to execute the PHP code when the event runs in order to keep your site secure. You should carefully and fully check the PHP code in the affected events. Consult the "My site was hacked" page on the WordPress.org documentation site if you find unexpected code.

If the security salts in the wp-config.php file on your site have been changed then this invalidates the stored hashes for the PHP code in all of your PHP cron events. Note that changing or rotating the security salts on your site will have several effects, including but not limited to:

• Logging out all users and invalidating all security nonces
• Invalidating hashes used within functionality such as comment moderation, Customizer controls, and widget management

Your security salts may also change if you move your site from one server to another and the salts in the wp-config.php file differ, or if you move your site from a staging environment to a production environment (or vice versa) and the salts differ.

In all of these cases, you should edit the affected PHP cron events, make absolutely sure that the code remains as intended, and save it again. This will cause the hash to be regenerated and saved alongside the PHP code, and the event will begin working as expected once again.

WP Crontrol enables you to take control of the cron events on your WordPress website. From the admin screens you can:

• View all cron events along with their arguments, recurrence, callback functions, and when they are next due.
• Edit, delete, pause, resume, and immediately run cron events.
• Add new cron events.
• Bulk delete cron events.
• Add and remove custom cron schedules.
• Export and download cron event lists as a CSV file.

Installation ​

Install and activate WP Crontrol as you would any other WordPress plugin. You can download it here on WordPress.org.

Manage cron events ​

Go to the Tools → Cron Events menu to manage cron events.

From here you can see a list of all the currently scheduled cron events. If there is a large number of events, you can search, filter, and page through the list.

Edit cron events ​

Click the Edit link next to an event to edit details such as its hook name, arguments, next run date, and recurrence.

Add a new cron event ​

There are two steps to creating a functioning cron event that executes regularly. The first step is telling WordPress about the hook. This is the part that WP Crontrol was created to provide. The second step is calling a function when your hook is executed.

Step one: Adding the hook ​

In the Tools → Cron Events admin panel, click on "Add New" and enter the details of the hook. You're best off using a hook name that conforms to normal PHP variable naming conventions. The event schedule is how often your hook will be executed. If you don't see a good interval, then add one first in the Settings → Cron Schedules admin panel.

Step two: Writing the function ​

This part takes place in PHP code (for example, in the functions.php file from your theme). To execute your hook, WordPress runs an action. For this reason, we need to tell WordPress which function to execute when this action is run. The following line accomplishes that:

add_action( 'my_hookname', 'my_function' );

The next step is to write your function. Here's a simple example:

function my_function() {
	wp_mail( 'hello@example.com', 'WP Crontrol', 'WP Crontrol rocks!' );
}

Add a new PHP cron event ​

See here for full information about PHP cron events.

Pause cron events ​

Pausing a cron event is a way to prevent an event from running. This is more reliable than deleting an event because many plugins will immediately recreate events that are missing.

Pausing an event will disable all actions attached to the event's hook. The event itself will remain in place and will run according to its schedule, but all actions attached to its hook will be disabled. This renders the event inoperative but keeps it scheduled so as to remain fully compatible with events which would otherwise get automatically rescheduled when they're missing.

As pausing an event actually pauses its hook, all events that use the same hook will be paused or resumed when pausing and resuming an event. This is much more useful and reliable than pausing individual events separately.

Delete cron events ​

Click the Delete link next to an event to delete it. If no Delete link is shown, it usually means the event is created by the WordPress core software and therefore cannot be deleted. If you want to remove the functionality, you can pause the event instead (see above).

If more than one event exists with a given hook name, you can delete all of them at once via the "Delete all events with this hook" link next to one of the events.

Bulk delete cron events ​

You can delete multiple cron events by checking the checkboxes next to the events you wish to delete, then choosing the Delete option from the Bulk Actions menu, and clicking Apply. Events without a checkbox are events created by the WordPress core software and cannot be deleted.

Export cron events ​

A CSV file of the event list can be exported and downloaded via the "Export" button. This file can be opened in any spreadsheet application.

Manage cron schedules ​

In order to run at a recurring interval, a cron event needs to use a cron schedule. If the built-in cron schedules don't suit your needs then you can use WP Crontrol to add new schedules.

Go to the Settings → Cron Schedules menu to manage cron schedules.

If you're seeing an error message saying there was a problem spawning a call to the WP-Cron system on your site, this indicates a problem that is preventing cron events from running. If you can see cron events that have missed their schedule by more than a few minutes, this is almost certainly a problem you need to investigate.

What should I do? ​

Firstly, please do not open a support thread on the WP Crontrol plugin forum as nobody will be able to assist you there. There are better places and ways to get support for this problem.

1. Reload the page a few times to determine if the error is persistent. If the error only appears once then it may have been a temporary network connectivity problem.
2. If the error persists, make a note of the error message. Common errors are listed below with more information about what they mean.
3. Try deactivating the other plugins on your site one by one. It could be that one of them is causing a problem.
4. If your website is hosted on a managed WordPress service, contact your web host and send them the error message. They are best positioned to assist you and they've probably seen the same problem before.
5. If you're not using a managed WordPress hosting service, try searching for the error message using your favourite search engine or on the support forums of your web host.
6. If you cannot diagnose the problem, post the error message in a new thread on the main wordpress.org support forums where hopefully a volunteer can assist you.

Common errors ​

cURL error 6: Could not resolve domain ​

This means there is a problem with the DNS configuration of your domain or your server. The domain name is not pointing to a valid IP address, or your server does not have up to date DNS information.

cURL error 7: Failed to connect: Connection refused ​

This is a bit of a mystery error. It could relate to your HTTPS configuration, or it could be an access restriction problem (see below). This may be a temporary network connectivity problem.

cURL error 28: Operation timed out after 3000 milliseconds with 0 bytes received ​

This means there is a network connectivity problem preventing your server from performing "loopback" requests to itself.

cURL error 35: sslv3 alert handshake failure ​

This means there's a problem with your HTTPS configuration. Your server cannot securely connect to itself.

Unexpected HTTP response code: 401 or 403 ​

This means an access control restriction such as BasicAuth, a firewall, a security or privacy plugin, some form of password protection, or an .htaccess rule is preventing your server from accessing wp-cron.php.

Unexpected HTTP response code: 404 ​

This means the wp-cron.php file in the root of your website has been deleted. Try reinstalling WordPress from the Dashboard → Updates screen.

Unexpected HTTP response code: 500 or higher ​

This means an error has occurred on your server which is preventing the cron spawner from running. Check the error logs on your server.

The WP-Cron system in WordPress is not a "real" cron system, which means events may not run exactly according to their schedule because the system relies on regular traffic to the website in order to trigger scheduled events.

The WP Crontrol plugin does not alter the way that WordPress core runs or stores cron events.

Reasons WP-Cron events can miss their schedule ​

• Low traffic websites may not trigger the event runner often enough
• A fatal error caused by a plugin or theme may break the event runner
• A plugin or theme may intentionally or unintentionally break the event runner
• BasicAuth, a firewall, password protection, or other access restrictions may block the event runner
• A problem with your web hosting or web server may break the event runner
• Long-running events may temporarily block the event runner
• High traffic websites may suffer from sequential processing issues that block the event runner
• The DISABLE_WP_CRON configuration constant is set but no alternative cron runner has been put in place
• An alternative cron runner is in place but is not working as expected or has stalled

How can I fix this? ​

There's no single solution to this problem. Your best approach is to:

1. Reload the page a few times to determine if the problem is persistent. If the issue only appears occasionally then it could be that low levels of traffic to your site is the cause. Continue reading for more info.
2. Read the Problems spawning a call to the WP-Cron system page.
3. Deactivate other plugins on your site one by one to see if any of them are causing things to break. Start with ones that you've recently updated or recently installed.
4. Contact your web hosting provider as they commonly have experience dealing with problems with WP-Cron. They'll often recommend setting up a server-level cron job to trigger the WP-Cron event runner.
5. Read the sections below on how to set up a server-level cron job or reliably run WP-Cron events at a large scale.

Articles with more information ​

• WordPress Handbook: Hooking WP-Cron Into the System Task Scheduler
• SpinupWP: Understanding WP-Cron

Host-specific instructions ​

• SiteGround: How to replace WP-Cron with a real cron job
• Pantheon: Configuring and optimizing the WP-Cron feature
• WP Engine: WP-Cron and WordPress event scheduling
• Kinsta: How to Disable WP-Cron for Faster Performance
• DreamHost: Disabling WP-Cron to Improve Overall Site Performance
• Rocket.net: How Do I Disable WP-Cron In WordPress?
• Altis: No need to do anything, cron is handled by Cavalcade
• WordPress.com VIP: No need to do anything, cron is handled by Cron Control

Running events via WP-CLI ​

If you have access to WP-CLI and Crontab on your server, you can set up a real schedule in Crontab and use it to run all pending WP-Cron events via WP-CLI. Here are some articles on this topic:

• Better wp-cron using linux's crontab
• How to run WordPress cron with WP CLI via crontab

WP-Cron at scale ​

If you need to process a large number of cron events, your events are long-running, you need parallel processing, or you require high reliability for your cron events, you should consider one of the following:

• Cavalcade
• Cron Control

Background processing ​

If you need to perform long-running actions in a background process, try one of these:

• Action Scheduler
• WP Queued Jobs

If you need an approach that doesn't use WP-Cron, try one of these:

• WP Background Processing
• TLC Transients
• Async Transients
• DFM Transients

If you deactivate or delete the WP Crontrol plugin, your existing cron events will remain in place and will mostly continue to run as they would normally, with some exceptions detailed below.

Paused cron hooks ​

Any cron hooks that you've paused through WP Crontrol will be resumed because the paused functionality is provided by WP Crontrol. If you reactivate WP Crontrol, they will become paused again.

PHP cron events ​

If you've created a PHP cron event with WP Crontrol, these events will remain in place after you deactivate WP Crontrol but they will cease to operate because these events are processed by WP Crontrol. If you reactivate WP Crontrol, they will resume operating as normal.

Custom schedules ​

If you've created a custom cron schedule from the Settings → Cron Schedules screen, these schedules will no longer be available for use by cron events on your site because they get added by WP Crontrol.

Any cron event which uses a custom schedule will run at its next scheduled time as normal but will not subsequently get rescheduled and will disappear.

If you reactivate WP Crontrol, your custom schedules will become available for use again.

Edits to events ​

If you've edited a cron event and changed its arguments, next run time, or recurrence, these changes will persist because this data is stored in the standard WP-Cron system in WordPress.

Unfortunately the WP-Cron system in WordPress isn't totally reliable when editing, deleting, or adding new events, particularly on a site with many events so that one may be running right around the time you save your event, and on sites with a persistent object cache.

This problem is not specific to WP Crontrol and affects any WP-Cron management plugin.

If you try to add, delete, or edit a cron event and the changes aren't saved, there are a few things you can try to fix the issue.

How can I fix this? ​

• Ensure you're running WordPress 5.7 or later so WP Crontrol can show you more specific error messages. Prior to 5.7 there wasn't a way for cron management plugins to know the details about every error.
• Try again. Often the problem is sporadic and making the change a second time will work. For example this problem can occur if you make a change right at the time when a cron event is being run by WordPress.
• Ensure the event is not scheduled within 10 minutes of another event with the same hook. If the event is not a recurring event, WordPress core will block this "duplicate" event and the error message may not indicate this.
• Try deactivating any plugins that provide a persistent object cache, for example Redis or Memcached. This is not ideal of course, but it can help you get to the root of the problem.
• Read through the Cron events that have missed their schedule page. Much of the information there applies to creating and editing events too.

If you're seeing an error message saying This interval is less than the WP_CRON_LOCK_TIMEOUT constant it means the interval at which events with this schedule are due to run is less than the interval at which WordPress core actually runs events.

Why is this a problem? ​

While WordPress core runs a cron event it prevents further events from running to avoid multiple processes accidentally running the same event twice. The maximum duration of this "lock" is set by the WP_CRON_LOCK_TIMEOUT constant which by default is set to 60 seconds.

If an event takes longer than this duration to run, and events are scheduled with an interval of less than this duration, then those events will not run according to their schedule. They will run late.

Do I need to fix this? ​

You may not need to fix anything, but you should remain aware of the potential late-running problem above. If you notice events with this short interval are missing their schedules then you may need to address it.

How do I fix this? ​

Firstly, take a look at the Cron events that have missed their schedule page, there's lots of useful information on there.

Secondly, you should either adjust the interval at which the cron events run so they run less frequently, or decrease the value of WP_CRON_LOCK_TIMEOUT. The effects of changing this constant are a bit beyond the scope of this document but I'll try to add some more info here in the future.

WP Crontrol includes a feature that allows administrative users to create events in the WP-Cron system that execute PHP code, subject to the restrictive security permissions documented below.

Which users can manage PHP cron events? ​

Only users with the edit_files capability can manage PHP cron events in WP Crontrol. If a user does not have the capability to edit files in the WordPress admin area -- i.e. via the Plugin Editor or Theme Editor menu -- then they cannot add, edit, or delete a PHP cron event.

By default only Administrators have this capability, and with Multisite enabled only Super Admins have this capability.

If file editing has been disabled via either the DISALLOW_FILE_MODS or DISALLOW_FILE_EDIT configuration constant in WordPress then adding, editing, or deleting a PHP cron event will not be permitted.

Is this feature dangerous? ​

The user capability required to create, edit, and execute PHP code via WP Crontrol exactly matches that which is required to edit PHP files in a standard WordPress installation. Therefore, the user access level required to execute arbitrary PHP code does not change with WP Crontrol activated.

If you wish to prevent PHP cron events from being added or edited on your site then you can define either the DISALLOW_FILE_MODS or DISALLOW_FILE_EDIT configuration constant in your wp-config.php file.

How do I create a new PHP cron event? ​

In the Tools → Cron Events admin panel, click on "Add New". In the form that appears, select "PHP cron event" and enter the schedule and next run time. In the "PHP Code" area, enter the PHP code that should be run when your cron event is executed. Don't include the PHP opening tag (<?php).

Can I "lock" PHP cron events so that other users cannot edit them? ​

Yes. You can create or edit a PHP cron event, save it, and then define either the DISALLOW_FILE_MODS or DISALLOW_FILE_EDIT configuration constant as documented above to prevent further changes to the event from the Cron Events admin panel. The event will continue to run at its scheduled interval as expected but it will not be editable.

If you need to edit the event in the future, you can temporarily remove the relevant configuration constant, make your required changes to the event, and then reinstate the constant to re-lock it.

How can I create a cron event that requests a URL? ​

From the Tools → Cron Events → Add New screen, create a PHP cron event that includes PHP that fetches the URL using the WordPress HTTP API. For example:

wp_remote_get( 'http://example.com' );

Can the code in PHP cron events be tampered with? ​

The PHP code that's saved in a PHP cron event is protected with an integrity check which prevents it from being executed if the code is tampered with.

PHP cron events are secured via an integrity check that makes use of an HMAC to store a hash of the PHP code alongside the code when the event is saved. When the event runs, the hash is checked to ensure the integrity of the PHP code and confirm that it has not been tampered with. WP Crontrol will not execute the PHP code if the hashes do not match or if a stored hash is not present.

If an attacker with database-level access were to modify the PHP code in an event in an attempt to execute arbitrary code, the code would no longer execute.

Why do I see "Needs checking" next to my PHP cron events? ​

The integrity checking mechanism documented above was introduced in WP Crontrol 1.16.2 in March 2024. If you have PHP cron events stored on your site prior to updating to this version or later then you'll need to check and re-save your PHP cron events so the hash can be generated and saved alongside the PHP code.

Otherwise, if WP Crontrol is showing you a message saying your PHP cron events need to be checked, this could either mean there is a real problem caused by tampering of the PHP code in the events, or it could be caused by your security salts having been changed.

See here for complete information about PHP events which show "Needs checking".

If you're seeing an error message saying PHP default timezone is not set to UTC it means the timezone that PHP uses on your server has been changed from UTC to another timezone. This is a misconfiguration that you'll need to fix.

Why is this a problem? ​

The default timezone used by PHP should not be changed even when a non-UTC timezone is selected on the General Settings screen in WordPress. Doing so can cause timezone offset calculations in WordPress, plugins, and themes to be doubled up or cancelled out.

WP Crontrol highlights this problem because it can cause:

• Cron events to be missed completely or incorrectly scheduled
• Scheduled posts to be published at the wrong time or missed completely
• Cron events that you edit to use the wrong timezone

This is not a problem specific to WP Crontrol, and its effects are not confined to cron events. WordPress itself highlights this as a problem on the Site Health screen.

What's the cause? ​

Almost certainly the cause is some code in a plugin, a theme, or in wp-config.php which is calling the date_default_timezone_set function with a timezone value other than UTC.

How do I fix it? ​

You'll need to identify where the call to date_default_timezone_set is and remove it, after determining what other functionality on your site might be relying on its value. How you do that depends entirely on your site and is outside the scope of this help page.

Further reading ​

• Timezone documentation from WordPress.com VIP
• Date/Time component improvements in WordPress 5.3