npc01

NPC Maintenance Inspector performs 9-point health diagnostics on your WordPress site directly from the admin dashboard:
<ol>
<li>WordPress core updates — Detect missing core updates.</li>
<li>Plugin updates — List plugins with available updates.</li>
<li>Site Health issues — Extract critical issues from WP standard Site Health API.</li>
<li>PHP version — Warn on end-of-life PHP versions.</li>
<li>Error log analysis — Summarize debug.log entries and save a one-click backup to uploads/ for safe review.</li>
<li>File integrity — Detect suspicious code patterns in core files (eval / base64_decode / etc.) by comparing checksums against the WordPress.org Checksum API.</li>
<li>Suspicious files — Find unexpected PHP files in wp-content/uploads/, with built-in whitelist for known legitimate plugin files (Ajax Load More templates, WP STAGING index.php, AIOS firewall rules, etc.).</li>
<li>SSL certificate — Check days until expiration (warn under 30 days, critical at 0).</li>
<li>File permissions — Check critical files like wp-config.php, .htaccess, wp-content/.</li>
</ol>
Operational features:
<ul>
<li>History — Keep the last 10 diagnoses as a custom post type.</li>
<li>Scheduled auto-check — Run daily, weekly, or monthly via WP Cron.</li>
<li>Email notifications — Send alerts only on critical issues.</li>
<li>One-click debug.log clear — Truncate the log while preserving file permissions.</li>
<li>Optional AI report — Generate maintenance suggestions via Anthropic Claude API. Disabled by default; opt-in via a wp-config.php constant.</li>
</ul>
The plugin is locked to the user who activated it and to the original site URL, so it stays inert after backup restores to a different domain.
<h3>External services</h3>
This plugin can optionally connect to the Anthropic Claude API (<code>https://api.anthropic.com/v1/messages</code>) to generate AI-powered maintenance reports. This is the only external service the plugin ever contacts.
When is data sent?
<ul>
<li>When you manually click the “Generate AI Report” button in the admin.</li>
<li>When an automatic scheduled diagnosis detects a critical issue and notifications are enabled. In that case the AI report is generated once per critical run and attached to the notification email.</li>
</ul>
What data is sent?
<ul>
<li>The diagnosis result text only:
<ul>
<li>Site URL, site name, WordPress version, theme name</li>
<li>Counts of plugin updates / Site Health issues / error-log entries</li>
<li>PHP version, memory limit, max upload size</li>
<li>SSL expiration date and days remaining</li>
<li>File-permission status of critical files</li>
<li>Suspicious code patterns detected (function names like <code>eval</code>, <code>base64_decode</code>)</li>
</ul>
</li>
<li>No login data, no post content, no personal data of site visitors.</li>
</ul>
Is the data sent unconditionally?
No. The AI feature is completely disabled unless you define <code>NPCMI_API_KEY</code> in <code>wp-config.php</code>. Without that constant, no external connection to Anthropic is ever made.
Anthropic’s terms and privacy policy:
<ul>
<li>Consumer Terms of Service: https://www.anthropic.com/legal/consumer-terms</li>
<li>Privacy Policy: https://www.anthropic.com/legal/privacy</li>
<li>Commercial Terms of Service (if you use a paid API plan): https://www.anthropic.com/legal/commercial-terms</li>
</ul>
By enabling the AI report feature (i.e. by defining <code>NPCMI_API_KEY</code>), you agree to Anthropic’s applicable terms.

NPC Maintenance Inspector

WordPress maintenance health-check tool with 9-point diagnostics, history tracking, and optional AI-powered reports.

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: 
 cronheart_monitor( ‘my_nightly_report’, ‘xxxxxxxx-…’ );</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> / 
 success / <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 
 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.
<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.

NPC Maintenance Inspector vs Cronheart