WordPress Cron and Scheduled Tasks

WordPress's built-in cron system (WP-Cron) is designed to run scheduled tasks, such as publishing scheduled posts, checking for plugin updates, or running backups.

In Seravo's environment, WP-Cron works automatically out of the box, and developers do not need to configure anything special. By default, WP-Cron is triggered whenever a visitor loads the site.

Checking Scheduled Tasks

The list of scheduled events is unique for each site and depends on the plugins being used. The easiest way to check pending tasks is to connect to your site via SSH and use WP-CLI:

wp cron event list

The command outputs a list of all scheduled events:

+------------------------------+---------------------+-----------------------+------------+
| hook                         | next_run_gmt        | next_run_relative     | recurrence |
+------------------------------+---------------------+-----------------------+------------+
| wp_privacy_delete_old_export | 2026-03-15 11:18:22 | 1 minute 25 seconds   | 1 hour     |
| wp_update_plugins            | 2026-03-15 17:16:29 | 5 hours 59 minutes    | 12 hours   |
| wp_version_check             | 2026-03-15 17:18:01 | 6 hours 1 minute      | 12 hours   |
| sm_ping_daily                | 2026-03-15 18:20:52 | 7 hours 3 minutes     | 1 day      |
| wp_scheduled_auto_draft      | 2026-03-15 18:50:37 | 7 hours 33 minutes    | 1 day      |
+------------------------------+---------------------+-----------------------+------------+

Note the next_run_relative column: If multiple tasks show now or a past time (e.g., 1 hour ago) and remain stuck in that state even after refreshing the site, WordPress cron is likely failing. This is usually caused by a lack of site traffic, a plugin code error, or blocked PHP execution.

Testing and Running Cron Events Manually

WP-CLI includes a built-in feature to test the cron system. You can verify whether the site can successfully spawn cron events:

wp cron test

Successful output: Success: WP-Cron spawning is working as expected.

You can also try executing all due events manually. This is highly useful for troubleshooting when you need to see if a specific task gets stuck:

wp cron event run --due-now

Alternatively, you can trigger a single specific event by its hook name:

wp cron event run wp_update_plugins

If the command executes and no errors appear immediately in the terminal or in the /data/log/php-error.log file, the function was likely executed successfully.

Moving WP-Cron to the System Cron

Because the default WP-Cron only runs when a visitor loads a page, it comes with two potential drawbacks:

On low-traffic sites, scheduled tasks (like a post scheduled for 08:00) may be delayed if no one visits the site at that exact time.
On highly resource-intensive sites (such as WooCommerce stores), heavy cron executions can slow down page load times for visitors.

In these cases, we recommend disabling the visitor-triggered cron and replacing it with a server-level system cron, which runs tasks reliably in the background.

Step 1: Disable Visitor-Triggered Cron

Add the following constant to your project's wp-config.php file (or to .env if your site uses one):

define( 'DISABLE_WP_CRON', true );

Once added, visitors will no longer trigger background tasks.

Step 2: Add the Task to the System Crontab

Configure the server to run the WP-CLI command at a regular interval by adding a new rule to the server's crontab file using the command crontab -e:

* * * * * /usr/local/bin/wp cron event run --due-now >> /data/log/wp-cron.log 2>&1

This rule reliably executes all due cron tasks once per minute and logs any potential errors directly to the site's log directory at /data/log/wp-cron.log.

Note regarding curl and wget commands: Many older WordPress tutorials advise adding a system cron command that calls curl [https://example.com/wp-cron.php](https://example.com/wp-cron.php). This method is not recommended in Seravo's environment. It unnecessarily consumes nginx HTTP worker processes, whereas the direct wp cron event run command executes tasks much more efficiently at the PHP-FPM level.

Timezones and Time Handling

When developing time-critical schedules, it is important to understand how the server and WordPress handle time differently:

Server Time: The hardware clocks on Seravo's servers are always set to UTC, and the operating system timezone (date) is configured according to the server cluster's location (e.g., Finnish time).
WordPress Time: During execution, WordPress always forces the PHP timezone back to UTC.

Because of this, time inside WordPress (e.g., in plugin code or cron hooks) is always in UTC. When you want to output or manipulate time in the site's local timezone, always use WordPress's native time functions, such as wp_date(), current_time(), or the_time().

Example of time output on the same server:

# Operating system time (e.g., Finnish time)
date -R
Fri, 22 Mar 2026 10:00:00 +0200

# WordPress internal time (forced UTC)
wp eval "echo date('r');"
Fri, 22 Mar 2026 08:00:00 +0000

Common Issues and Troubleshooting

wp cron test returns an error (The DISABLE_WP_CRON constant is set to true): This notice is completely normal if the visitor-triggered WP-Cron has been disabled and replaced with a system-level cron. In this case, use the command crontab -l to verify that the background job (wp cron event run --due-now) is configured in the server's scheduler.
Tasks remain stuck (now or a past time in the next_run_relative column): The most common cause is a PHP error in a single plugin's cron hook or an HTTP password protection (Basic Auth) applied to the site, which blocks WordPress's internal HTTP requests. Test execution manually using wp cron event run --due-now and check for errors in /data/log/php-error.log.
Scheduled posts fail to publish on time: On sites with low traffic, the visitor-triggered WP-Cron may not run exactly at the scheduled publish time. Move the cron to the system level by following the instructions above to ensure tasks run reliably every minute.
Slow page loads or high server load: Heavy background tasks (such as WooCommerce's Action Scheduler) can congest PHP-FPM processes if they are executed during visitor page loads. Move the cron jobs to the system cron and, if necessary, review the Action Scheduler Optimization guide.