marksabbath

Tiago Hillebrandt

<a href="https://wp-healthcheck.com" rel="nofollow ugc">WP Healthcheck</a> is a plugin to check the health of your WordPress install.
It detects some useful information regarding your site health, like the number of active transients and autoload options, and then displays them conveniently via the WordPress Dashboard.
This plugin can help you improve your site performance by cleaning up the transients and deactivating autoload options.
WP Healthcheck also verifies the software versions in use by your server. We maintain information about software minimum requirements up to date in our systems. This allows the plugin to retrieve this information from our external API and compare versus the ones installed in your server.
SSL certificate expiration dates are also checked and notifications for expired or near expiration SSL certificates are provided conveniently via the WordPress Dashboard.
<h4>WP-CLI Extension</h4>
WP Healthcheck also includes a WP-CLI extension. If you want to see all the CLI commands available in the plugin, go ahead and run <code>wp healthcheck</code> in your site.
<ul>
<li><code>wp healthcheck autoload [--deactivate=<option-name>] [--history]</code></li>
<li><code>wp healthcheck transient [--delete-expired] [--delete-all]</code></li>
<li><code>wp healthcheck server</code></li>
<li><code>wp healthcheck ssl</code></li>
</ul>

WP Healthcheck

WP Healthcheck is a plugin to check the health of your WordPress install.

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 <a href="https://cronheart.com" rel="nofollow ugc">cronheart.com</a> 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.
<h4>What it does</h4>
<ul>
<li>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.</li>
<li>Per-event monitoring. Register any scheduled hook for start / success / fail pings with one PHP one-liner: <code>cronheart_monitor( 'my_nightly_report', 'xxxxxxxx-…' );</code></li>
<li>PHP fatal-error capture. When a scheduled callback fatals or throws, the fail-ping body includes the <code>error_get_last()</code> summary — the cronheart dashboard shows the cause without you tailing <code>debug.log</code>.</li>
<li>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).</li>
<li>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.</li>
<li>Configuration through <code>wp-config.php</code> constants for production (<code>CRONHEART_HEARTBEAT_UUID</code>, <code>CRONHEART_EVENT_<HOOK>_UUID</code>), with admin-UI fallback for sites where editing <code>wp-config.php</code> is not practical.</li>
</ul>
<h4>Never breaks WP-Cron</h4>
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 <code>wp_schedule_event</code> callbacks still run normally; you just stop seeing pings on the dashboard.
<h4>External services</h4>
This plugin sends HTTP requests to <a href="https://cronheart.com" rel="nofollow ugc">cronheart.com</a> 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:
<ul>
<li>The per-monitor UUID you configured (path segment).</li>
<li>A short body excerpt — capped at 10 KB — containing either an exception summary (for <code>fail</code> pings) or nothing (for <code>start</code> / <code>success</code> / <code>heartbeat</code>).</li>
<li>The plugin / SDK version in a <code>User-Agent</code> header.</li>
</ul>
2. Monitor listing (wp-admin only). When — and only when — you save a cronheart.com API token, the Settings → Cronheart page calls <code>https://cronheart.com/api/v1/monitors</code> to fetch your monitor list for the heartbeat picker. The request carries the token as an <code>Authorization: Bearer</code> 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.
<a href="https://cronheart.com/terms" rel="nofollow ugc">Cronheart.com Terms of Service</a> · <a href="https://cronheart.com/privacy" rel="nofollow ugc">Privacy policy</a>
<h4>Open source</h4>
Source code and issue tracker: <a href="https://github.com/alexander-po/cronheart-wp" rel="nofollow ugc">github.com/alexander-po/cronheart-wp</a>.
The plugin wraps the <a href="https://github.com/alexander-po/cron-monitor-php" rel="nofollow ugc"><code>cron-monitor/php-sdk</code></a> PHP package (also open source, MIT-licensed). Both projects are maintained independently.

Cronheart

Dead-man-switch monitoring for WP-Cron. Get alerted when scheduled events stop firing — uptime monitors do not catch this.

WP Healthcheck vs Cronheart