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.
• Account overview and monitor management. With a token configured, Settings → Cronheart shows your plan and monitor budget, and a “Your monitors” table listing each monitor with its status and any active snooze. From that table you can pause, resume, snooze (1 hour, 4 hours, 1 day, or 1 week), or unsnooze a monitor; the change applies on cronheart.com immediately. Every action is an authenticated administrator request — nothing happens without your click.
• Per-event monitoring UI. A new Settings → Cronheart Events screen lists the recurring WP-Cron events on your site and lets you, per event, either assign one of your monitors from a dropdown or auto-create an interval monitor for it in one click — no code required. This is the point-and-click alternative to the cronheart_monitor() helper and CRONHEART_EVENT_<HOOK>_UUID constants (both still work and take precedence).
• 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: the monitoring pings your scheduled jobs send, and the account-management calls the admin settings page makes. 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. Account management (wp-admin only). When — and only when — you save a cronheart.com API token, the Cronheart admin screens (Settings → Cronheart and Settings → Cronheart Events) talk to the cronheart.com management API at https://cronheart.com/api/v1/.... Every such request carries the token as an Authorization: Bearer header and runs only while a logged-in administrator is on one of those screens — and, for the write actions below, only when that administrator clicks the control. Never on the front end, during WP-Cron, or in any other context. No token, no request. The calls are:

• Read your monitors — GET /api/v1/monitors — to populate the heartbeat picker, the “Your monitors” table, and the per-event assignment dropdowns. Sends nothing beyond the token.
• Read your account — GET /api/v1/account — to show your plan, monitor budget, and API rate-limit standing. Sends nothing beyond the token.
• Lifecycle actions — POST /api/v1/monitors/<uuid>/pause (or /resume, /snooze, /unsnooze) — sent when you click a pause / resume / snooze / unsnooze button. Sends the monitor’s UUID (in the path) and the action; snooze also sends the chosen duration (1 hour, 4 hours, 1 day, or 1 week).
• Create a monitor — POST /api/v1/monitors — sent when you click “Auto-create & assign” for a recurring event on the Cronheart Events screen. Sends the event’s hook name (as the monitor name), its schedule as an interval in seconds, the site timezone, and a grace period — all derived from the WP-Cron schedule.

The lifecycle and create calls are the only requests that change anything on cronheart.com, and each is one deliberate click. The token is optional: without it the plugin makes none of these management calls — you assign monitors by hand (or via the constants / helper) and only the monitoring pings above are ever sent.

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.