外掛標籤
開發者團隊
原文外掛簡介
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_
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.
