Cronheart

WP-Cron is request-driven. On a low-traffic site no requests arrive, no events fire, and a scheduled backup can be stalled for weeks before anyone notices. Uptime monitors do not catch this — the site responds to HTTPS just fine, it just is not running its jobs.

Cronheart turns WP-Cron into a dead-man switch: the plugin pings cronheart.com every five minutes and on every individual event you register. If the pings stop, cronheart alerts you via email, Telegram, Slack, Discord, or a custom webhook.

What it does

• Site heartbeat. A 5-minute custom WP-Cron event whose only job is to ping cronheart. Proves WP-Cron itself is alive on this site.
• Per-event monitoring. Register any scheduled hook for start / success / fail pings with one PHP one-liner: cronheart_monitor( 'my_nightly_report', 'xxxxxxxx-…' );
• PHP fatal-error capture. When a scheduled callback fatals or throws, the fail-ping body includes the error_get_last() summary — the cronheart dashboard shows the cause without you tailing debug.log.
• Settings page. A read-only “Monitored events” table at Settings → Cronheart shows every hook the plugin is watching and where its UUID came from (constant, option, filter).
• Monitor picker. Save a cronheart.com API token and the site heartbeat field becomes a dropdown of your account’s monitors instead of a hand-typed UUID. Entirely optional — without a token you paste the UUID as before, and any API hiccup falls back to that field. The token is write-only and never leaves wp-admin.
• Configuration through wp-config.php constants for production (CRONHEART_HEARTBEAT_UUID, CRONHEART_EVENT_<HOOK>_UUID), with admin-UI fallback for sites where editing wp-config.php is not practical.

Never breaks WP-Cron

The plugin’s hard contract: a broken cronheart backend, an unreachable network, a misbehaving PSR-18 HTTP client — none of them may cause WP-Cron to fail. Every network / HTTP error is swallowed into a logged warning. If cronheart goes down for a day, your wp_schedule_event callbacks still run normally; you just stop seeing pings on the dashboard.

External services

This plugin sends HTTP requests to cronheart.com in two distinct situations. Both are opt-in: without configuration the plugin loads and does nothing — no telemetry, no usage statistics, no anonymous reports.

1. Monitoring pings (front end / WP-Cron). Sent on every scheduled WP-Cron run, but only when you supply a monitor UUID. The exact data sent per ping:

• The per-monitor UUID you configured (path segment).
• A short body excerpt — capped at 10 KB — containing either an exception summary (for fail pings) or nothing (for start / success / heartbeat).
• The plugin / SDK version in a User-Agent header.

2. Monitor listing (wp-admin only). When — and only when — you save a cronheart.com API token, the Settings → Cronheart page calls https://cronheart.com/api/v1/monitors to fetch your monitor list for the heartbeat picker. The request carries the token as an Authorization: Bearer header and runs only while a logged-in administrator is viewing that settings page — never on the front end, during WP-Cron, or in any other context. No token, no request. The token is optional; without it you simply paste a monitor UUID by hand and this call is never made.

Cronheart.com Terms of Service · Privacy policy

Open source

Source code and issue tracker: github.com/alexander-po/cronheart-wp.

The plugin wraps the cron-monitor/php-sdk PHP package (also open source, MIT-licensed). Both projects are maintained independently.