Cron Monitor

Good to know

• Alerts are off until you turn them on.
• Alerts go only to the email address and webhook you set up; nothing else leaves your site. No tracking, no ads.
• Deleting the plugin removes everything it created.

Technical details

WP-CLI

• wp cronmon runs : recorded runs. Filters: --hook , --status , --since , --limit . The limit is a whole number from 1 to 1000 (default 20); anything else is an error, not rounded.
• wp cronmon health : the Cron Health findings. Exits non-zero when one is critical.
• wp cronmon orphans : every event with its safe-to-delete verdict. --verdict shows only one verdict: active , unknown , cron-only , orphaned , paused or excluded . Any other value is an error, not an empty list.

All three accept --format=json .

REST API

Both routes require manage_options . Use Application Passwords over HTTPS.

• GET /wp-json/cronmon/v1/health : the Cron Health findings, a critical count and an ok boolean for Uptime Kuma, Zabbix, Better Stack and similar monitors.
• GET /wp-json/cronmon/v1/runs?status=fatal&since=-1%20hour&limit=20 : recorded runs. Timestamps are ISO 8601 UTC.

Logging from your own code

Inside a cron callback, attach a note to the current run:

do_action( 'cronmon_log', 'reindexed 412 products' );

With Cron Monitor inactive, the call does nothing.

Server cron setup

Add to wp-config.php :

define( 'DISABLE_WP_CRON', true );

Then add a system cron entry, every five minutes:

*/5 * * * * cd /path/to/wordpress && wp cron event run --due-now > /dev/null 2>&1

Or, without WP-CLI:

*/5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Cron Monitor never writes to wp-config.php .

How it works

• A run is recorded when it starts, not when it finishes, so crashes and timeouts still leave a record.
• Cron Monitor attaches itself to every scheduled hook, so a hook with no callbacks now fires and is recorded as “0 callbacks”. Nothing else changes.
• Duplicates are matched on hook, arguments and schedule together. One-off events are never removed automatically.
• Late-running cron is traced to the job that held the cron lock too long, and a WP_CRON_LOCK_TIMEOUT value is recommended.

Performance

• Front-end page views load two small PHP files and run no queries. With alerts on, one or two queries are added unless you have a persistent object cache.
• Each cron job adds two database writes, one when it starts and one when it finishes.
• Measured instrumentation cost is about 0.005 ms and 2.7 KB per cron job (PHP 8.4, one machine).

What this plugin stores

Two database tables per site:

• cronmon_runs : one row per run. Hook name, an md5 hash of the arguments (never the values), timing, memory, query count, outcome, and the first error message (up to 2,000 characters). If your own code calls cronmon_log , its notes are stored on the run too: up to 50 notes of 500 characters each, and 8,000 characters in all per run.
• cronmon_hooks : one row per scheduled event, with the callbacks last seen on it and who owns them. Rows for events that never ran and have no guard or pinned time are pruned.

Options, in the WordPress options table:

• cronmon_settings : your settings, including the alert email address and webhook URL.
• cronmon_recording_enabled : whether run history is switched on.
• cronmon_paused : the jobs you have paused.
• cronmon_schedules : your custom schedules.
• cronmon_blocked : the last 20 attempts the duplicate guard refused.
• cronmon_changelog : the jobs that appeared or disappeared recently.
• cronmon_alert_item_* : one row for each alert waiting to be delivered, at most 200, each dropped after 24 hours. cronmon_alert_queue is the older single-row version of this queue and only exists on sites upgraded from before 1.5.2.
• cronmon_overdue_next_check : when the stopped-running check may next run.
• cronmon_webhook_next_attempt : when the alert webhook may next be tried. After a webhook request fails, it rests for 5 minutes.
• cronmon_db_version : the database version of the two tables.

Transients (short-lived cache entries):

• cronmon_alerted_* : one per job that raised an alert, so the same job is not alerted again within your throttle period.
• cronmon_overdue_seen : the overdue job seen by the stopped-running check.
• cronmon_spawn_status : the result of the wp-cron.php check, cached for an hour.
• cronmon_critical_findings : the count shown in the menu badge, cached for an hour.
• cronmon_event_form_<user id> : the values you typed into the Add event form if it was refused, kept for 2 minutes so the form can be filled in again.
• cronmon_request_error_<user id> : an error message to show you once, kept for 1 minute.
• cronmon_install_retry : set for 5 minutes after a failed table install, so the install is not retried on every request.

By default, successful runs are kept for 7 days and failures for 14, capped at 50,000 rows. You can change all three under Tools → Cron Monitor → Settings . No IP addresses, user names or visitor data are stored. The only user information is your own user ID in the names of the last two transients, and the alert email address you enter yourself.

Everything above is removed on uninstall. The one exception is a cronmon_alerted_* transient on a site with a persistent object cache, which cannot be found by name and expires on its own within your throttle period.

No third-party libraries are bundled and nothing is minified.

External services

This plugin contacts no third-party service of its own. No analytics, no update checker. It makes at most two kinds of outbound request, both under your control:

• Alert webhook (optional, off by default): sent to the URL you enter, typically Slack or Discord. A request is made only when alerts and the webhook are switched on and a job crashes, runs late or stops running, or when you press Send test alert . It is sent at the end of the page request, and if it fails it is retried later, no sooner than 5 minutes after, and dropped after 24 hours. The JSON body contains these keys: event (fatal, drift or overdue), hook (the job’s hook name), args_hash (an md5 hash, never the arguments), site (your site’s home URL), url (a link to Run History in your WordPress admin), started_at , duration (null for drift and overdue alerts), and message, text and content (the same one-sentence summary, which includes your site’s home URL; Slack reads text and Discord reads content ). Depending on the event it also has error (the truncated error message of a crash), count (how many jobs are overdue), late_by , gap and expected (seconds). Your site’s home URL is therefore sent to the service you chose. Terms and privacy policies: Slack terms and privacy policy ; Discord terms and privacy policy .
• Loopback check : the Cron Health screen, Site Health test and REST health route can ask your own wp-cron.php whether it answers. This goes to your own site_url() . It never runs during cron or WP-CLI, is cached for an hour, and is skipped where something else manages cron (Cavalcade, Cron Control, DISABLE_WP_CRON , ALTERNATE_WP_CRON ).

Alert emails are sent through wp_mail() to the address you enter, using your site’s own mail setup.