What is WordPress Cron (WP-Cron)?

Table of Contents 5 sections

What is WordPress Cron?

WordPress Cron, commonly referred to as WP-Cron, is a task scheduling system built into WordPress core that manages the execution of time-based events. Unlike a traditional Unix cron daemon that runs continuously in the background and executes tasks at precise intervals based on system time, WP-Cron is a "pseudo-cron" that is triggered by incoming HTTP requests to the site. When a visitor loads any page on a WordPress site, WordPress checks whether any scheduled tasks are overdue and executes them during that page load. This design was chosen to ensure compatibility with shared hosting environments where site owners do not have access to system-level cron services.

WP-Cron handles a variety of essential WordPress functions including publishing scheduled posts at their designated time, checking for core, plugin, and theme updates, sending scheduled email notifications, processing transient cleanup, and executing any custom scheduled events registered by plugins. Plugins like backup solutions, security scanners, and email marketing tools heavily rely on WP-Cron to perform their periodic tasks. Without a functioning WP-Cron system, scheduled posts would not publish on time, security scans would not run, and backups would not be created.

How WP-Cron Works

When a page request is received, WordPress checks the cron option in the database, which contains a serialised array of all scheduled events and their next execution times. If any events are overdue, WordPress spawns a separate HTTP request to wp-cron.php to process them asynchronously, allowing the original page request to complete without delay. This spawned request processes all due events sequentially, executing their registered callback functions in order.

Developers schedule events using wp_schedule_event() for recurring tasks and wp_schedule_single_event() for one-time tasks. Each scheduled event is associated with a hook name and an optional set of arguments. When the event is due, WordPress fires the associated action hook, and any callbacks registered to that hook are executed. WordPress provides three default recurrence intervals: hourly, twicedaily, and daily. Plugins can register custom intervals using the cron_schedules filter to support more frequent or less frequent execution patterns.

WP-Cron Security Concerns

The most significant security concern with WP-Cron is that wp-cron.php is publicly accessible and can be triggered by anyone sending an HTTP request to it. Attackers can abuse this by flooding the endpoint with requests, potentially causing a denial-of-service condition as WordPress repeatedly processes cron events, consumes server resources, and triggers database operations. On high-traffic sites, the default behaviour of checking for cron events on every page load can also degrade performance as multiple simultaneous requests may attempt to spawn cron processing concurrently.

Another security consideration is that plugins can schedule cron events that execute arbitrary code at regular intervals. A malicious plugin could register a cron event that periodically phones home to a command-and-control server, exfiltrates data, or re-establishes a backdoor even after the malicious plugin has been deactivated. Because cron events are stored in the database and persist across plugin deactivations, simply removing a malicious plugin does not necessarily remove its scheduled tasks. Administrators should audit the cron event schedule using tools like WP Crontrol to identify and remove any suspicious or unexpected scheduled events.

Replacing WP-Cron with System Cron

For improved reliability and security, many administrators replace the default WP-Cron trigger mechanism with a real system-level cron job. This involves two steps: first, disabling the default WP-Cron trigger by adding define('DISABLE_WP_CRON', true); to wp-config.php, which prevents WordPress from checking for due events on every page load. Second, configuring a system cron job that sends an HTTP request to wp-cron.php at a regular interval, typically every five to fifteen minutes.

This approach provides several security and performance benefits. Cron events execute at predictable intervals regardless of site traffic, ensuring that scheduled tasks like security scans and backups run reliably even on low-traffic sites. The performance impact on page loads is eliminated because the cron check no longer occurs during user requests. The system cron job can be configured to use WP-CLI (wp cron event run --due-now) instead of HTTP requests, which avoids exposing wp-cron.php to the web entirely and executes cron events directly on the command line, providing a more secure and efficient execution context.

WP-Cron Security Best Practices

Restricting access to wp-cron.php at the web server level is an important hardening measure when using a system cron job. Apache and Nginx can be configured to deny HTTP access to wp-cron.php from all sources except localhost or the specific IP address of the cron job runner. This prevents external parties from triggering cron execution and eliminates the endpoint as a potential denial-of-service vector. If WP-CLI is used for cron execution, the file can be blocked from web access entirely.

Regular auditing of scheduled cron events should be part of every WordPress security maintenance routine. Tools like the WP Crontrol plugin provide a visual interface for viewing all registered cron events, their schedules, and their associated callback functions. Any events with unfamiliar hook names, unusually frequent schedules, or callbacks pointing to unknown functions should be investigated as potential indicators of compromise. Plugins should clean up their cron events when deactivated or uninstalled by implementing proper deactivation hooks that call wp_clear_scheduled_hook() to remove their scheduled tasks from the database.