WP-CLI running WordPress cron job safely on Linux server

How to Safely Run WordPress Cron Jobs via WP-CLI

, , , ,

Series: WordPress Performance on DirectAdmin (Rocky Linux 9)

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

How to Safely Run WordPress Cron Jobs via WP-CLI

Introduction

WordPress relies on a pseudo-cron system that triggers scheduled tasks when users visit the site. On high-traffic or mission-critical sites managed with DirectAdmin on Rocky Linux 9, this method is inefficient and unreliable. The best practice is to disable WordPress’s built-in wp-cron.php and replace it with a system cron job that runs WP-CLI. This guide details a safe, reproducible approach tailored for sysadmins managing DirectAdmin-hosted WordPress sites.

Why Replace the Default WordPress Cron?

  • Performance: Reduces unnecessary PHP processes on every page load.
  • Reliability: Ensures scheduled tasks run on time, regardless of site traffic.
  • Control: System cron jobs are easier to monitor and tune per domain.

Prerequisites

  • SSH access with sudo privileges on a Rocky Linux 9 server.
  • DirectAdmin-managed account(s) hosting WordPress sites.
  • WP-CLI installed globally (/usr/local/bin/wp recommended).
  • PHP-FPM in use (DirectAdmin’s default for new installations).

Step 1: Install or Update WP-CLI (if needed)

If not already present, install WP-CLI for system-wide use:

sudo dnf install -y php-cli wget
sudo wget https://github.com/wp-cli/wp-cli/releases/latest/download/wp-cli.phar -O /usr/local/bin/wp
sudo chmod +x /usr/local/bin/wp
wp --info

Confirm wp is available and shows valid output.

Step 2: Identify Site and PHP-FPM Pool Details

For DirectAdmin, each domain typically has its own PHP-FPM pool file in /usr/local/directadmin/data/users/<user>/php-fpmXX.conf (XX = PHP version). To check which user and PHP version serve your domain:

cd /usr/local/directadmin/data/users/
grep -R "domain.com" *

Note the PHP version and system username for later steps.

Step 3: Disable WordPress’s Built-in Cron

Edit wp-config.php in the document root. Add the following line above /* That's all, stop editing! */:

define('DISABLE_WP_CRON', true);

Warning: This disables all automatic background task execution via HTTP. If you do not immediately follow with a working system cron, scheduled events will cease to run.

Step 4: Create a System Cron Job for WP-CLI

Use the site’s DirectAdmin system user (e.g., user1) to avoid permission issues and use the correct PHP-FPM pool. Example for a domain example.com:

  1. Switch to the user:
    sudo -u user1 -i
  2. Edit their crontab:
    crontab -e
  3. Add this line to run every 5 minutes (good starting value):
    */5 * * * * cd /home/user1/domains/example.com/public_html && /usr/local/bin/wp cron event run --due-now --quiet >> /home/user1/wp-cron.log 2>&1

This runs due cron events directly using WP-CLI and logs output to wp-cron.log for troubleshooting.

Checklist: Cron Job Best Practices

  • Use the correct system user for the domain.
  • Set working directory to the WordPress root (public_html).
  • Use –quiet to reduce log noise.
  • Log output for error tracking.
  • Test with /usr/local/bin/wp cron event run –due-now before enabling.

Step 5: Testing and Verification

Manual Trigger

sudo -u user1 -i
cd /home/user1/domains/example.com/public_html
wp cron event run --due-now --allow-root

Check for errors. If the site uses special PHP versions or custom pools, specify the path with --path= and --php=/usr/bin/phpXX as appropriate.

Monitor Cron Execution

  • Tail the log file:
    tail -f /home/user1/wp-cron.log
  • Check the cron daemon status:
    sudo systemctl status crond
  • Verify scheduled events in WordPress:
    wp cron event list

HTTP Response Testing

With DISABLE_WP_CRON set, requests to /wp-cron.php via browser or curl will have no effect. To validate that page loads are unaffected:

curl -I https://example.com/

For load testing, use wrk or k6 to confirm improved request latency:

sudo dnf install -y wrk
wrk -t2 -c10 -d30s https://example.com/

Step 6: Adjusting for NGINX/Apache and DirectAdmin Panel Templates

DirectAdmin uses web server templates for per-domain configuration. If you manage many sites or want to enforce DISABLE_WP_CRON by default, consider modifying the relevant template (e.g., php-fpm.conf, nginx_php.conf in /usr/local/directadmin/data/templates/). Warning: Template changes affect all new domains and may require a web server reload:

sudo systemctl reload httpd   # For Apache
sudo systemctl reload nginx   # For NGINX

Apply these changes during a maintenance window to avoid brief downtime.

Per-Domain PHP Tuning

If cron jobs trigger heavy PHP usage, consider editing the user’s PHP-FPM pool file to reserve higher pm.max_children or longer request_terminate_timeout values for that user. After changes:

sudo systemctl reload php-fpm

Monitor top or htop for unexpected load spikes.

Step 7: Troubleshooting

  • Permission errors: Ensure the cron job runs as the correct system user and has access to the site directory.
  • PHP version mismatch: Confirm WP-CLI uses the correct PHP binary; DirectAdmin may install multiple versions.
  • “Another cron process is running”: Stagger cron jobs for multiple sites to avoid locking conflicts.
  • Missed events: Check wp-cron.log and wp cron event list for overdue tasks.

Step 8: Security and Maintenance

  • Restrict cron job editing to trusted sysadmins.
  • Periodically audit wp-cron.log for errors or unexpected output.
  • Keep WP-CLI and PHP versions up to date (test before updating in production).
  • Use DirectAdmin’s user-level cron interface for tighter control if delegating to end users.

Conclusion

Managing WordPress cron jobs via WP-CLI with system cron is a robust, scalable approach for DirectAdmin/Rocky Linux 9 environments. It improves both reliability and site performance, provided you align the cron job with your PHP-FPM configuration and test all changes methodically. For multi-site servers, document your cron setup and monitor logs proactively to catch issues early.

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

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

Next: Scheduled Posts Not Publishing? WP-Cron Timing Explained

Smart reads for curious minds

We don’t spam! Read more in our privacy policy