內容簡介
Cronheart 將 WP-Cron 轉變為一個死手開關，透過每五分鐘向 cronheart.com 發送請求來確保計劃任務正常運行，並在請求停止時即時通知使用者，避免因低流量造成的任務延遲。
【主要功能】
• 站點心跳監控，確保 WP-Cron 正常運作
• 每個事件的監控，輕鬆註冊計劃任務
• 捕捉 PHP 致命錯誤，提供錯誤摘要
• 設定頁面顯示所有監控事件
• 監控選擇器，簡化 UUID 輸入
• 帳戶概覽與監控管理，隨時調整監控狀態
外掛標籤
開發者團隊
原文外掛簡介
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 sends a start, success or fail ping on every run of each event you register. With an optional API token, its wp-admin screens let you assign monitors to events, pause or snooze them, test your alert channels and read recent pings without leaving WordPress. If the pings stop, cronheart alerts you via email, Telegram, Slack, Discord, Microsoft Teams, Google Chat, PagerDuty, or a signed 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. This holds for runs through a page request, wp-cron.php, ALTERNATE_WP_CRON and WP-CLI’s wp cron event run.
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 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_
Channel management. A Settings → Cronheart Channels screen lists your cronheart.com notification channels and lets you, per channel, send a real test alert through it or — for webhook channels — rotate the signing secret (revealed once). Creating channels stays on cronheart.com; this screen tests and maintains the ones you already have.
Ping & alert history. A Settings → Cronheart History screen shows the most recent pings (kind, time, runtime) and alerts (kind, time, channels notified) for a monitor you pick (the picker lists up to 200 monitors) — a read-only at-a-glance log without leaving WordPress.
Configuration through wp-config.php constants for production (CRONHEART_HEARTBEAT_UUID, CRONHEART_EVENT_
Requirements
WordPress 6.0 or later.
PHP 8.2 or later with the cURL extension (curl), which most hosts enable.
A cronheart.com account; the free plan is enough. An API token is optional.
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; with WP_DEBUG and WP_DEBUG_LOG on, a ping that fails leaves one line in the debug log. A third-party filter that throws while the plugin reads its settings is caught too. If cronheart goes down for a day, your wp_schedule_event callbacks still run normally; you just stop seeing pings on the dashboard. When the plugin cannot send pings safely (the PHP cURL extension is missing, or the endpoint setting is one it does not accept), it sends none and shows an error notice in wp-admin instead.
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 — capped at 10 KB — that is empty for start / success / heartbeat pings. For a fail ping it holds the PHP error type, the file path and line, and the message of the fatal error or uncaught exception, or a one-line note that the event did not complete.
The bundled SDK’s name and version in a User-Agent header (for example cron-monitor-php-sdk/1.9).
2. Account management (wp-admin only). When — and only when — you save a cronheart.com API token, the Cronheart admin screens (Settings → Cronheart, Settings → Cronheart Events, Settings → Cronheart Channels, and Settings → Cronheart History) 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, the per-event assignment dropdowns, and the Cronheart History monitor picker. Sends nothing beyond the token and paging parameters.
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/
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 — plus an idempotency key that is a SHA-256 hash of the site URL and the hook name (the URL itself is not sent), so a repeated click does not create a second monitor.
Read your channels — GET /api/v1/channels — to populate the Cronheart Channels screen. Sends nothing beyond the token.
Send a test alert — POST /api/v1/channels/
Rotate a webhook secret — POST /api/v1/channels/
Read ping & alert history — GET /api/v1/monitors/
The lifecycle, create, test, and rotate-secret calls are the only requests that change anything — and “Send test” additionally delivers a real notification to the channel’s destination, while “Rotate secret” invalidates the old webhook secret — but each is one deliberate administrator 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.
