Why You Should Disable WP-Cron (And Use Linux Cron Instead)

Series: WordPress Performance on DirectAdmin (Rocky Linux 9)

Phase 4: Cron, Automation & Background Tasks — Part 13 of 30

Why You Should Disable WP-Cron (And Use Linux Cron Instead) on DirectAdmin Rocky Linux 9

Overview

WordPress relies on a built-in pseudo-cron system (WP-Cron) to execute scheduled tasks. However, WP-Cron’s default behavior triggers on site visits, which can cause performance and reliability problems—especially on DirectAdmin-managed Rocky Linux 9 servers. Replacing WP-Cron with a native Linux cron job provides better control, reliability, and efficiency. This article details why and how to safely migrate, with a focus on DirectAdmin specifics.

Problems with WP-Cron on DirectAdmin Servers

Request-based Triggers: WP-Cron runs only when users visit the site. Low-traffic sites may miss scheduled tasks; high-traffic sites may trigger overlapping jobs, causing load spikes.
PHP-FPM Pool Limits: DirectAdmin configures PHP-FPM pools per domain. WP-Cron jobs can consume available workers, potentially blocking real user requests.
Concurrency Issues: Multiple overlapping cron triggers can result in database contention and race conditions.
Unpredictable Execution: There’s no guarantee WP-Cron jobs will run at precise intervals, which is problematic for time-sensitive automation.
Resource Wastage: Each WP-Cron request requires a full PHP process, even if no jobs are pending.

Benefits of Using System Cron on Rocky Linux 9

Consistent Scheduling: System cron ensures jobs run at exact times, regardless of website traffic.
Reduced Load: No unnecessary PHP-FPM pool usage—jobs run only when needed.
Greater Control: You can monitor, log, and throttle jobs at the OS level.
Reliability: System cron is a tested, robust scheduler. No missed jobs due to HTTP issues or user inactivity.

Step-by-Step: Disabling WP-Cron and Using Linux Cron

Checklist Before You Begin

Backup your wp-config.php and current cron settings.
Ensure you have shell access and sudo privileges.
Identify the PHP version and handler (DirectAdmin may use per-domain PHP-FPM pools).
Verify the WordPress root path (often /home/username/domains/example.com/public_html).
Check that traffic is low or plan for a maintenance window (disabling WP-Cron may briefly delay scheduled jobs).

1. Disable WP-Cron in WordPress

To prevent WordPress from triggering cron jobs on user requests, add the following line to wp-config.php above the /* That's all, stop editing! */ line:

define('DISABLE_WP_CRON', true);

Risk: If you make a syntax error, WordPress will become unavailable. Always test after editing.

Test with WP-CLI:

cd /home/username/domains/example.com/public_html
wp cli check-update

If you see any PHP errors, restore your backup and re-edit carefully.

2. Create a System Cron Job

We recommend running the WordPress cron every 5 minutes. Adjust the path and PHP version as needed (see DirectAdmin’s PHP selector or php -v).

Determine the correct PHP binary for the user/domain. Usually, DirectAdmin symlinks php to the active version in /usr/local/bin/php or /opt/alt/php-fpmXX/usr/bin/php. To check, run:
```
sudo -u username which php
```
Replace username as appropriate. If PHP is not in $PATH, use the full path shown by DirectAdmin for the domain’s PHP version.
Create or edit the user’s crontab:
```
sudo -u username crontab -e
```
Add this cron line, adjusting paths as needed:
```
*/5 * * * * /usr/local/bin/php -q /home/username/domains/example.com/public_html/wp-cron.php >/dev/null 2>&1
```
- -q suppresses PHP startup messages.
- Output is sent to /dev/null to reduce log noise. Remove or adjust for troubleshooting.

3. Optional: Centralize Cron for Multiple Sites

If managing many WordPress sites, consider a root-level cron job. However, be aware this can create file permission issues if sites run under different users. For tight security, prefer user-level crons per site.

4. Confirm Cron Permissions and SELinux Contexts

Rocky Linux 9 may use SELinux. If enabled, confirm cron jobs are allowed to execute PHP and access the WordPress directory. Check the SELinux mode:

sestatus

If in enforcing mode and you encounter permission denials, review /var/log/audit/audit.log and adjust contexts as needed. For most default DirectAdmin setups, this is not an issue.

5. Reload or Restart Cron (if necessary)

The crond service automatically picks up new user crontabs. Only restart if you edited /etc/crontab or system-wide files:

sudo systemctl reload crond

Testing and Monitoring Your New Cron Setup

Manual Trigger for Immediate Testing

You can manually trigger the WP-Cron tasks to ensure correct execution. Use WP-CLI:

cd /home/username/domains/example.com/public_html
wp cron event run --due-now

Alternatively, run the PHP cron directly and observe any output:

sudo -u username /usr/local/bin/php -q /home/username/domains/example.com/public_html/wp-cron.php

Log Monitoring

Check for PHP errors:

tail -f /home/username/domains/example.com/logs/error.log

Review cron logs:
```
sudo journalctl -u crond -f
```
Note: Cron output goes to user mail by default. Set up MAILTO="" in the crontab to suppress mail, or check the user’s mailbox for errors.

Performance Testing

After migration, confirm that site response times are stable and no longer spike during cron events. Use wrk or curl for basic testing:

wrk -c 20 -d 30s https://example.com/

Check the PHP-FPM pool status if suspicious load persists:

sudo systemctl status php-fpm

Or for a specific pool (e.g., php-fpm81-example.com):

sudo systemctl status php-fpm81-example.com

Tuning and Scaling Considerations

DirectAdmin PHP-FPM Pool Settings

Each cron job consumes a PHP-FPM worker. If you run multiple sites on the same server, review and adjust pool settings in /usr/local/directadmin/data/users/username/php-fpm.conf or the relevant template. Typical starting values:
- pm.max_children = 5
- pm.start_servers = 2
- pm.min_spare_servers = 1
- pm.max_spare_servers = 3
After changes, reload PHP-FPM:
```
sudo systemctl reload php-fpm81-example.com
```
Downtime warning: An incorrect PHP-FPM config can cause site outages. Test after reloading.

Nginx/Apache Considerations

If you use NGINX as a proxy or standalone, no special changes are required for offloading cron to the system level. If you have custom DirectAdmin templates that rate-limit or block wp-cron.php requests, review them to avoid accidentally blocking your system cron job.

Rollback Plan

If issues arise after migration, simply comment out or remove DISABLE_WP_CRON in wp-config.php and remove the system cron entry. Site operation will revert to the default behavior.

Summary and Recommendations

Disable WP-Cron in wp-config.php to prevent inefficient, traffic-based scheduling.
Set up a user-level system cron job for each WordPress install, matching the PHP path and domain ownership.
Monitor logs and PHP-FPM pools after migration for any issues.
Adjust cron frequency and pool limits based on observed load and task volume.

Note: This article offers general technical guidance. Validate all configurations in a safe environment before applying them to production.

Previous: MariaDB Performance Tuning for WordPress on Rocky Linux

Next: How to Safely Run WordPress Cron Jobs via WP-CLI