This is an advanced manual setup and is not the recommended solution for a low-traffic MainWP Dashboard. Direct worker files invoke specific MainWP tasks; they do not replace WordPress’s complete cron and background-event processing.For most installations, keep MainWP Dashboard > Settings > Advanced Settings > Use WP Cron enabled and configure the server to request wp-cron.php every minute. Follow Manage WP Cron on a Low-Traffic MainWP Dashboard. What You’ll Learn
- How MainWP’s cron control differs from WordPress’s
DISABLE_WP_CRON setting
- How the recommended low-traffic setup differs from direct-worker mode
- Which MainWP Dashboard and Add-on workers can be invoked directly
- Which scheduled work direct workers do not cover
Prerequisites
- Access to your server’s cron system, such as cPanel, Plesk, or SSH
- Knowledge of your MainWP Dashboard WordPress installation path
- The PHP binary location on your server
- A complete inventory of enabled MainWP features and Add-ons
Understand the cron controls
Cron event registration, cron triggering, and direct worker execution are separate mechanisms:
- MainWP Use WP Cron controls whether MainWP Dashboard and compatible MainWP Add-ons register and retain their recurring events in WordPress’s cron queue. Turning it off removes the MainWP recurring hooks that honor this setting. It does not disable WordPress WP-Cron globally.
DISABLE_WP_CRON is a WordPress-wide setting. define( 'DISABLE_WP_CRON', true ); stops normal page visits from spawning WP-Cron, but it does not remove registered events.- A server request to
wp-cron.php processes due registered events even when DISABLE_WP_CRON is true. It cannot recreate MainWP recurring hooks removed by turning Use WP Cron off.
- A server scheduler using WP-CLI can run due registered events with
wp cron event run --due-now even when DISABLE_WP_CRON is true. It does not rely on normal page visits.
- A direct MainWP worker invokes only that worker’s callback. It does not dispatch WordPress’s general WP-Cron queue.
WordPress documents its external scheduler pattern in Hooking WP-Cron Into the System Task Scheduler.
Select the correct cron configuration
Recommended low-traffic setup
Keep Use WP Cron enabled and do not configure individual MainWP worker files. Have the server request wp-cron.php every minute:
After verifying that the direct wp-cron.php trigger runs reliably, you can prevent normal page visits from also spawning WP-Cron by adding:
When enabled, normal visits no longer spawn WP-Cron, but a direct server request to wp-cron.php or a scheduler running wp cron event run --due-now continues to process due registered events. If an uptime monitor requests only the Dashboard homepage or another normal page, leave DISABLE_WP_CRON undefined or set it to false. Enable it only after verifying a direct external runner is reliable. If it is enabled without one, scheduled WordPress events can stop processing. This setting is unrelated to MainWP’s Use WP Cron toggle.
Avoid mixed or incomplete configurations:
- Use WP Cron enabled with matching direct worker jobs: The same work may be invoked twice.
- Use WP Cron disabled with only
wp-cron.php requested: MainWP recurring hooks removed by the setting do not exist for wp-cron.php to run.
DISABLE_WP_CRON enabled without an external runner: The ordinary WordPress cron queue can stall.DISABLE_WP_CRON enabled with only homepage or normal-page requests: Those requests cannot spawn WP-Cron; target wp-cron.php directly or use a WP-CLI runner.- Direct worker files only: Specific handlers run, but queued follow-up events and recurring tasks without direct files may not run.
If you require complete MainWP Dashboard and Add-on behavior, use the recommended low-traffic configuration.
Enable direct-worker mode
Before switching, inventory every enabled MainWP feature and Add-on and identify all required workers. Do not execute files merely because they exist in a plugin’s /cron directory.
Inventory enabled functionality
Record every MainWP Dashboard feature and Add-on that relies on scheduled processing, including multi-stage workflows.
Turn off Use WP Cron
Turn off MainWP Dashboard > Settings > Advanced Settings > Use WP Cron. This removes the MainWP recurring schedules controlled by the setting; it does not disable WordPress WP-Cron globally.
Configure each documented worker
Create a separate server job for every required worker at the exact cadence shown below.
Verify feature results
Confirm that expected data, state changes, and notifications are saved. A successful command response alone is not sufficient verification.
Direct PHP invocation is the primary command format within this advanced mode. It avoids the HTTP request path, but the PHP process can still fail or time out.
For MainWP Dashboard core jobs:
For MainWP Add-on jobs:
Use the job-specific examples below to identify the correct cron filename. For Add-on jobs, take both the Add-on directory and cron filename from the documented path.
Alternative HTTP invocation
If direct PHP execution is unavailable, use an HTTPS request with the complete job-specific plugin directory and filename:
Replace /path/to/public_html with the MainWP Dashboard WordPress installation path and /usr/bin/php with the correct PHP binary. Hosting providers document cron setup for tools such as cPanel and Plesk. The > /dev/null 2>&1 redirection discards all output, including errors. Temporarily remove it during troubleshooting or redirect output to a log file. A successful HTTP response, exit code 0, or OK log entry proves only that the command returned successfully. It does not prove that all sites were processed or that results were saved.
Understand direct-worker coverage
Direct worker files cover only the callbacks documented below. MainWP Dashboard, MainWP Add-ons, WordPress, and other plugins can also schedule one-time events or background actions without a corresponding direct PHP file. Therefore, this method is not a feature-complete replacement for WordPress WP-Cron.
- Multi-stage Add-ons require independent start and continuation jobs at their documented cadences.
- Calling a start worker, waiting briefly, and calling the continuation worker once does not drain a queue. Continuation workers must run repeatedly.
- A returned command does not establish that queued sites were processed successfully or that results were stored.
- Direct worker requirements can change between MainWP Dashboard and Add-on releases. Review this page and current source after every update.
Direct workers by product
Core
Cost Tracker Assistant
Domain Monitor
Lighthouse
Maintenance
Patchstack
Post Dripper
Pro Reports
Regression Testing
Sucuri
SSL Monitor
Vulnerability Checker
Process Update Checks and Automatic Updates
Frequency: *every minute (crontab schedule: * * * * )Runs MainWP’s incremental update-check and automatic-update workflow, including continuation and related notification handling.Ping Child Sites
Frequency: *every day (crontab schedule: 0 0 * * )Requests wp-cron.php on managed Child Sites so their due WordPress events can run.Run Built-in Uptime Monitoring
Frequency: *every minute (crontab schedule: * * * * )Runs built-in Uptime Monitoring.Send Deactivated License Alerts
Frequency: *every day (crontab schedule: 0 0 * * )Sends notifications when MainWP detects deactivated MainWP Add-on licenses and the deactivated_license_alert notification is enabled.Run General Schedules
Frequency: *every minute (crontab schedule: * * * * )Runs registered MainWP regular-sequence processes incrementally. It is not the general WordPress WP-Cron dispatcher and does not execute arbitrary due WP-Cron events.Start Legacy Backups
Frequency: *every hour (crontab schedule: 0 * * * )Continue Legacy Backups
Frequency: *every 5 minutes (crontab schedule: */5 * * * )Configure these two workers only when the built-in MainWP Legacy Backup feature is enabled. They do not run backup Add-ons.
Send Site Health Notifications
Frequency: *every hour (crontab schedule: 0 * * * )Sends Site Health notifications from stored monitoring data when Site Health Monitoring is enabled.Reconnect Sites
Frequency: *every hour (crontab schedule: 0 * * * )Send Cost Tracker Alerts
Frequency: *every day (crontab schedule: 0 0 * * )Checks active Cost Tracker Assistant subscriptions and sends configured renewal alert emails when a subscription is within the notification window.This worker sends alerts only when Cost Tracker Assistant is enabled. Email notifications for cost_tracker_notification_email and the Cost Tracker Assistant notification option must also be enabled.
Start Domain Monitor
Frequency: *every day (crontab schedule: 0 0 * * )Continue Domain Monitor
Frequency: *every 5 minutes (crontab schedule: */5 * * * )Create both jobs separately. Running the start worker daily does not force every domain to be checked daily. Domain Monitor still respects the configured global or per-site checking frequency. The continuation worker processes due domains in batches and then handles expiration notifications. Keep it scheduled every five minutes; one continuation run does not drain all queued work.Newly connected sites are enrolled in Domain Monitor automatically. The daily start worker reconciles connected sites before calculating which domains are due, and the five-minute continuation worker resumes reconciliation when more sites remain. A manual first domain check is no longer required. Domain checks still follow the configured global or per-site frequency, and existing manual or disabled per-site profiles keep their settings.
domain_monitor_cron_alert.php is currently unused and must not be configured as a separate cron job. Alert processing belongs to the continuation flow.
Use Core General Schedules
Current Lighthouse audits and notifications are integrated with MainWP Core General Schedules. When mainwp/cron/generalschedules.php runs every minute, no additional Lighthouse worker is required.Compatibility alternative: lighthouse_cron_start.php and lighthouse_cron_sync.php both call the same combined audit and notification handler. Treat those files as an alternative route to Core General Schedules, not as additional required jobs, and do not configure both routes. lighthouse_cron.php is currently a no-op and must not be configured as a notification job.
Start Maintenance
Frequency: *every hour (crontab schedule: 0 * * * )Continue Maintenance
Frequency: *every minute (crontab schedule: * * * * )Start Patchstack Synchronization
Frequency: *every day (crontab schedule: 0 0 * * )Continue Patchstack Synchronization
Frequency: *every 5 minutes (crontab schedule: */5 * * * )Synchronize the Patchstack Dashboard
Frequency: *every day (crontab schedule: 0 0 * * )These workers respect the Patchstack API sync frequency setting. Run the daily workers even when the Add-on is set to weekly or monthly synchronization; the Add-on skips work until it is due.
These direct workers cover Patchstack synchronization. Patchstack notification emails can be queued as one-time WordPress cron events, which these files do not dispatch. For complete scheduled behavior, use the recommended WP-Cron configuration. Drip Articles
Frequency: *every hour (crontab schedule: 0 * * * )Send Report Notifications
Frequency: *every hour (crontab schedule: 0 * * * )Send Reports
Frequency: *every 5 minutes (crontab schedule: */5 * * * )Continue Reports
Frequency: *every minute (crontab schedule: * * * * )Start Regression Testing
Frequency: *every day (crontab schedule: 0 0 * * )Sets the scheduled-run state and timestamp. It does not perform site or page scans.Continue Regression Testing
Frequency: *every 5 minutes (crontab schedule: */5 * * * )Selects eligible work and queues one-time WordPress cron events for page processing. It does not itself execute the page scans or later processing stages.These two direct files are not a complete server-cron replacement for Regression Testing. Actual page processing, subsequent batches, CSS/JavaScript tracking, and notifications rely on one-time WordPress cron events. Daily snapshot optimization also has no direct PHP entry file.For complete automatic Regression Testing behavior, keep Use WP Cron enabled and trigger wp-cron.php externally every minute. Requesting wp-cron.php while Use WP Cron remains disabled does not restore the recurring snapshot-optimization hook.
Send Notifications and Reminders
Frequency: *every day (crontab schedule: 0 0 * * )Handles configured Sucuri notifications or reminders. It does not initiate Sucuri security scans.Start SSL Monitor
Frequency: *every day (crontab schedule: 0 0 * * )Continue SSL Monitor
Frequency: *every 5 minutes (crontab schedule: */5 * * * )Create both jobs separately. Running the start worker daily does not mean every certificate is checked daily. The configured automatic-check frequency still determines when each site is due. The continuation worker processes due checks in batches and handles alerts afterward. Keep it scheduled every five minutes; one continuation run does not drain all queued work.Newly connected HTTPS sites are enrolled in SSL Monitor automatically. The daily start worker reconciles connected sites before calculating which certificates are due, and the five-minute continuation worker resumes reconciliation when more sites remain. A manual first certificate check is no longer required. HTTP-only sites are skipped because SSL Monitor checks HTTPS certificates.
Process Vulnerability Checks
Frequency: *every 10 minutes (crontab schedule: */10 * * * )
Self-Check Checklist
