> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mainwp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Run MainWP Workers Directly with Server Cron

> Advanced reference for invoking individual MainWP Dashboard and Add-on workers with server cron, including important limitations and coverage differences from WordPress WP-Cron.

<Warning>
  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 **top-right user menu > MainWP Settings > Advanced Settings > Use WP Cron** (`/wp-admin/admin.php?page=SettingsAdvanced`) enabled and configure the server to request `wp-cron.php` every minute. Follow [Manage WP Cron on a Low-Traffic MainWP Dashboard](/customization/manage-wp-cron-on-low-traffic-mainwp-dashboard).
</Warning>

This page documents the individual workers currently available for administrators who intentionally choose to maintain direct server cron jobs.

## 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](https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler/).

***

## Select the correct cron configuration

| Setup | MainWP Use WP Cron | `DISABLE_WP_CRON` | Server configuration | Coverage |
| - | - | - | - | - |
| Normal traffic-dependent WP-Cron | Enabled | Not defined or `false` | No external trigger required | Page visits trigger registered events, but execution can be late on low-traffic MainWP Dashboard installations |
| Recommended low-traffic setup | Enabled | Depends on the trigger: `false` for normal-page requests; `true` with a verified direct `wp-cron.php` or WP-CLI runner | Trigger the general WP-Cron queue every minute | Dispatches due registered WordPress, MainWP Dashboard, and Add-on events through the general WP-Cron queue |
| Advanced direct-worker setup | Disabled | Independent setting | Configure every required direct worker at its exact cadence | Runs only explicitly invoked callbacks and is not a complete WP-Cron replacement |

### 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:

```bash theme={null}
* * * * * curl -fsS 'https://example.com/wp-cron.php?doing_wp_cron' > /dev/null 2>&1
```

After verifying that the direct `wp-cron.php` trigger runs reliably, you can prevent normal page visits from also spawning WP-Cron by adding:

```php theme={null}
define( 'DISABLE_WP_CRON', true );
```

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.

<Warning>
  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](/customization/manage-wp-cron-on-low-traffic-mainwp-dashboard).
</Warning>

***

## 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.

<Steps>
  <Step title="Inventory enabled functionality">
    Record every MainWP Dashboard feature and Add-on that relies on scheduled processing, including multi-stage workflows.
  </Step>

  <Step title="Turn off Use WP Cron">
    Turn off **top-right user menu > MainWP Settings > Advanced Settings > Use WP Cron** (`/wp-admin/admin.php?page=SettingsAdvanced`). This removes the MainWP recurring schedules controlled by the setting; it does not disable WordPress WP-Cron globally.
  </Step>

  <Step title="Configure each documented worker">
    Create a separate server job for every required worker at the exact cadence shown below.
  </Step>

  <Step title="Verify feature results">
    Confirm that expected data, state changes, and notifications are saved. A successful command response alone is not sufficient verification.
  </Step>
</Steps>

***

## Configure direct-worker commands

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:

```bash theme={null}
/usr/bin/php /path/to/public_html/wp-content/plugins/mainwp/cron/CRON-FILE > /dev/null 2>&1
```

For MainWP Add-on jobs:

```bash theme={null}
/usr/bin/php /path/to/public_html/wp-content/plugins/ADD-ON-DIRECTORY/cron/CRON-FILE > /dev/null 2>&1
```

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:

```bash theme={null}
curl -fsS 'https://example.com/wp-content/plugins/PLUGIN-DIRECTORY/cron/CRON-FILE' > /dev/null 2>&1
```

<Note>
  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](https://docs.cpanel.net/cpanel/advanced/cron-jobs/) and [Plesk](https://docs.plesk.com/en-US/obsidian/customer-guide/websites-and-domains/scheduling-tasks-cron-jobs.html).
</Note>

<Warning>
  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.
</Warning>

***

## Understand direct-worker coverage

<Warning>
  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.
</Warning>

* 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

<Tabs>
  <Tab title="Core">
    #### Process Update Checks and Automatic Updates

    **Frequency:** \*every minute (crontab schedule: \* \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp/cron/updatescheck.php > /dev/null 2>&1
    ```

    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 \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp/cron/pingchilds.php > /dev/null 2>&1
    ```

    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: \* \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp/cron/checkstatuschilds.php > /dev/null 2>&1
    ```

    Runs built-in [Uptime Monitoring](/sites/management/uptime-monitoring).

    #### Send Deactivated License Alerts

    **Frequency:** \*every day (crontab schedule: 0 0 \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp/cron/deactivatedlicensesalert.php > /dev/null 2>&1
    ```

    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: \* \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp/cron/generalschedules.php > /dev/null 2>&1
    ```

    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 \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp/cron/backups.php > /dev/null 2>&1
    ```

    #### Continue Legacy Backups

    **Frequency:** \*every 5 minutes (crontab schedule: \*/5 \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp/cron/backups_continue.php > /dev/null 2>&1
    ```

    <Note>
      Configure these two workers only when the built-in MainWP Legacy Backup feature is enabled. They do not run backup Add-ons.
    </Note>

    #### Send Site Health Notifications

    **Frequency:** \*every hour (crontab schedule: 0 \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp/cron/sitehealthmonitoring.php > /dev/null 2>&1
    ```

    Sends Site Health notifications from stored monitoring data when Site Health Monitoring is enabled.

    #### Reconnect Sites

    **Frequency:** \*every hour (crontab schedule: 0 \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp/cron/stats.php > /dev/null 2>&1
    ```
  </Tab>

  <Tab title="Advanced Uptime Monitor">
    #### Refresh Uptime Robot Data

    **Frequency:** \*every hour (crontab schedule: 0 \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/advanced-uptime-monitor-extension/cron/advanced-uptime-monitor-uptimerobot-hourly-refresh.php > /dev/null 2>&1
    ```

    Refreshes stored 24-hour uptime ratios for a small batch of Uptime Robot monitors per run and synchronizes recent incidents. The worker rotates through all monitors across successive runs, so every monitor is refreshed over time.

    <Note>
      This worker processes Uptime Robot monitors only and runs only from the command line. HTTP requests to the file return `403`, so the `curl` variant cannot be used for this job.
    </Note>
  </Tab>

  <Tab title="Cost Tracker Assistant">
    #### Send Cost Tracker Alerts

    **Frequency:** \*every day (crontab schedule: 0 0 \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-cost-tracker-assistant-extension/cron/cost-tracker-assistant-alert.php > /dev/null 2>&1
    ```

    Checks active Cost Tracker Assistant subscriptions and sends configured renewal alert emails when a subscription is within the notification window.

    <Note>
      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.
    </Note>
  </Tab>

  <Tab title="Domain Monitor">
    #### Start Domain Monitor

    **Frequency:** \*every day (crontab schedule: 0 0 \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-domain-monitor-extension/cron/domain_monitor_cron_start.php > /dev/null 2>&1
    ```

    #### Continue Domain Monitor

    **Frequency:** \*every 5 minutes (crontab schedule: \*/5 \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-domain-monitor-extension/cron/domain_monitor_cron_continue_run.php > /dev/null 2>&1
    ```

    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.

    <Info>
      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.
    </Info>

    <Note>
      `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.
    </Note>
  </Tab>

  <Tab title="Lighthouse">
    #### 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.

    <Note>
      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.
    </Note>
  </Tab>

  <Tab title="Maintenance">
    #### Start Maintenance

    **Frequency:** \*every hour (crontab schedule: 0 \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-maintenance-extension/cron/cron_job_start.php > /dev/null 2>&1
    ```

    #### Continue Maintenance

    **Frequency:** \*every minute (crontab schedule: \* \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-maintenance-extension/cron/cron_job_continue.php > /dev/null 2>&1
    ```
  </Tab>

  <Tab title="Patchstack">
    #### Start Patchstack Synchronization

    **Frequency:** \*every day (crontab schedule: 0 0 \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-patchstack-extension/cron/cron_start.php > /dev/null 2>&1
    ```

    #### Continue Patchstack Synchronization

    **Frequency:** \*every 5 minutes (crontab schedule: \*/5 \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-patchstack-extension/cron/cron_continue.php > /dev/null 2>&1
    ```

    #### Synchronize the Patchstack Dashboard

    **Frequency:** \*every day (crontab schedule: 0 0 \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-patchstack-extension/cron/cron_sync_dashboard.php > /dev/null 2>&1
    ```

    <Note>
      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.
    </Note>

    <Warning>
      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](/customization/manage-wp-cron-on-low-traffic-mainwp-dashboard).
    </Warning>
  </Tab>

  <Tab title="Post Dripper">
    #### Drip Articles

    **Frequency:** \*every hour (crontab schedule: 0 \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-post-dripper-extension/cron/post_dripper.php > /dev/null 2>&1
    ```
  </Tab>

  <Tab title="Pro Reports">
    #### Send Report Notifications

    **Frequency:** \*every hour (crontab schedule: 0 \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-pro-reports-extension/cron/notice_reports.php > /dev/null 2>&1
    ```

    #### Send Reports

    **Frequency:** \*every 5 minutes (crontab schedule: \*/5 \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-pro-reports-extension/cron/send_reports.php > /dev/null 2>&1
    ```

    #### Continue Reports

    **Frequency:** \*every minute (crontab schedule: \* \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-pro-reports-extension/cron/continue_reports.php > /dev/null 2>&1
    ```
  </Tab>

  <Tab title="Regression Testing">
    #### Start Regression Testing

    **Frequency:** \*every day (crontab schedule: 0 0 \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-regression-testing-extension/cron/html-regression-cron-start.php > /dev/null 2>&1
    ```

    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 \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-regression-testing-extension/cron/html-regression-cron-continue-run.php > /dev/null 2>&1
    ```

    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.

    <Warning>
      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.
    </Warning>
  </Tab>

  <Tab title="Sucuri">
    #### Send Notifications and Reminders

    **Frequency:** \*every day (crontab schedule: 0 0 \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-sucuri-extension/cron/securityscan_notification.php > /dev/null 2>&1
    ```

    Handles configured Sucuri notifications or reminders. It does not initiate Sucuri security scans.
  </Tab>

  <Tab title="SSL Monitor">
    #### Start SSL Monitor

    **Frequency:** \*every day (crontab schedule: 0 0 \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-ssl-monitor-extension/cron/ssl_monitor_cron_start.php > /dev/null 2>&1
    ```

    #### Continue SSL Monitor

    **Frequency:** \*every 5 minutes (crontab schedule: \*/5 \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-ssl-monitor-extension/cron/ssl_monitor_cron_continue_run.php > /dev/null 2>&1
    ```

    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.

    <Info>
      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.
    </Info>
  </Tab>

  <Tab title="Vulnerability Checker">
    #### Process Vulnerability Checks

    **Frequency:** \*every 10 minutes (crontab schedule: \*/10 \* \* \* *)*

    ```bash theme={null}
    /usr/bin/php /path/to/public_html/wp-content/plugins/mainwp-vulnerability-checker-extension/cron/vulnercheck.php > /dev/null 2>&1
    ```
  </Tab>
</Tabs>

***

## Self-Check Checklist

* [ ] I understand that direct-worker mode is advanced and not equivalent to full WP-Cron processing
* [ ] **Use WP Cron** is disabled only because direct-worker mode was intentionally selected
* [ ] Every required worker has its own server job at the documented cadence
* [ ] Start and continuation workers are configured separately
* [ ] MainWP recurring hooks and matching direct workers are not both running
* [ ] `DISABLE_WP_CRON` is not enabled unless a general external WP-Cron runner is working
* [ ] Legacy Backup workers are configured if the Legacy Backup feature is enabled
* [ ] Regression Testing uses the recommended WP-Cron setup when complete automation is required
* [ ] Newly connected sites appear in Domain Monitor, and eligible HTTPS sites appear in SSL Monitor, after automatic reconciliation
* [ ] Actual saved data and feature-specific results were verified, not only command exit status

***

## Related Resources

* [Manage WP Cron on a Low-Traffic MainWP Dashboard](/customization/manage-wp-cron-on-low-traffic-mainwp-dashboard) - Recommended configuration
* [WordPress: Hooking WP-Cron Into the System Task Scheduler](https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler/)
* [MainWP System Requirements](/advanced/miscellaneous/mainwp-system-requirements) - Server requirements
* [How to Change Update Frequency](/sites/updates/how-to-change-daily-update-and-sync-frequency) - Update scheduling


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.