Most monitors tell you the site is down. Site Agent tells you the plugin that just updated, the admin who just logged in, the fatal that just fired, and the WooCommerce gateway that just started returning 500s — right there in the incident, on the same page as the outage.
Every WordPress outage I’ve ever debugged came down to "what changed just before this" — a plugin auto-updated, a theme switched, an admin edited the homepage, PHP threw a fatal in a fresh release. Without a timeline, you SSH in and start grepping. Site Agent runs inside WordPress, captures every operational signal as it happens, and renders the answer next to the alert.
Each event is a single timestamped row with a human sentence ("Plugin updated: WooCommerce v9.4.2 → v9.4.3 by admin@…"), a severity, and the metadata to act on it.
Install, activate, deactivate, update and delete — with old/new versions, who triggered it, and the plugin slug. "WooCommerce auto-updated from 9.4.2 to 9.4.3 at 03:14" is one row in the timeline.
Active-theme changes and theme updates — the single most common cause of "the homepage looks broken now" tickets after a Friday deploy.
Every WordPress core upgrade is captured with the from/to version, so a core-induced regression has a row to point at instead of a guess.
Captured through WordPress’ shutdown handler with file:line and a plugin/theme/core attribution hint. Checkout-context fatals on WooCommerce sites get their own severity so silent cart failures stop being silent.
New admin user, deleted admin, role changes, admin logins — with a hashed IP so you can see "admin logged in from a new IP at 02:11" without storing addresses in plaintext.
Failed-login bursts per IP, first-time admin IP detection, sensitive option changes (siteurl, home, admin_email, default_role, users_can_register), and a daily wp-config sweep checking for DISALLOW_FILE_EDIT and WP_DEBUG_DISPLAY drift.
Rolling samples of request duration, memory peak and query count from admin and cron requests. Slow-request and memory-pressure events fire when a request crosses configurable thresholds.
Overdue cron events, DISABLE_WP_CRON detection, and stalled-heartbeat warnings — so a misconfigured cron stops being the silent reason your daily emails don’t send.
Failed orders, payment-gateway errors, checkout validation failures, checkout-fatal events, and WC system-status warnings — with zero customer, order or basket detail. Operational health only.
Daily diff of WordPress core files against api.wordpress.org checksums and plugin file-hash diffing. Bounded to a safe per-run budget so the integrity check never spikes load. Off by default; one click to enable.
A compact snapshot every few minutes: WordPress version, PHP version, active theme, plugin count, WooCommerce status, memory limit, performance trend. Renders as a live "current state" card in Monitrova next to the timeline.
Optional: the last N lines of wp-content/debug.log are scanned for PHP notices, warnings and stack traces and surfaced as low-severity events — useful for catching errors that don’t fatally crash the request but still indicate something is wrong.
When a site goes down at 03:14, this is the kind of row Monitrova shows on the incident page — alongside the uptime probe that failed.
Uncaught Error: Call to undefined method WC_Cart::get_basket()
in wp-content/plugins/some-plugin/includes/cart.php:142 — attributed to some-plugin v3.7.1.
some-plugin auto-updated from v3.7.0 to v3.7.1 by wp-cron. Likely root cause.
admin@… signed in from a hashed IP not previously seen for this site. Captured for the audit trail; no action required unless unexpected.
WordPress 6.7.2 · PHP 8.2.18 · WooCommerce active · theme twentytwentyfour-child · memory peak 84 MB / 256 MB · 47 queries · slow-request flag set.
Designed by an engineer who runs WooCommerce sites and refuses to install plugins that exfiltrate customer data.
The agent emits zero HTML on the frontend. No JS injected, no DOM nodes added, no extra HTTP calls during a visitor’s request. Heartbeats, queue retries and debug-log scans all run on WP-Cron, off the critical path.
By default the agent SHA-256 hashes every IP and User-Agent before sending. Passwords, cookies, session tokens, order data, customer email, basket contents — never collected. Plugin Check / wp.org compliance passes cleanly.
Failed sends go to a bounded local queue (capped at 100 items) and retry via WP-Cron every 5 minutes. Each event is attempted at most 5 times. A Monitrova outage can’t flood your database with backlog.
Tokens are SHA-256 hashed at rest in Monitrova — the raw secret is shown once on creation and never recoverable. Every ingest request is verified against the bound site URL, so a token pasted into the wrong WordPress install is rejected with HTTP 403 and a clear site_url_mismatch error.
The plugin is a single ZIP built on demand by your own Monitrova instance, so the version you download always matches the platform you’re sending to.
Requires WordPress 5.6+, PHP 7.4+. WooCommerce is detected at runtime — you only get the WooCommerce signal stream if the plugin is active. Multisite is supported.
No. Uptime, SSL and homepage health work on every plan including Free — the agent is purely additive. Add it on the WordPress sites where you want a timeline of internal changes alongside the external probes.
Site Agent is included from Starter upwards. The Free plan shows what Site Agent would capture, with a one-click upgrade button. See the pricing page for the full plan comparison.
No measurable impact on frontend requests. The agent emits zero frontend HTML, doesn’t hook into wp_head/wp_footer, and pushes all heavy work (heartbeat, queue retry, debug-log scan, integrity check) onto WP-Cron. Slow-request thresholds are operator-configurable.
Checkout-context fatals get their own severity tag so a silent cart crash stops being silent. WooCommerce operational signals (failed orders, gateway errors, checkout validation failures, WC system status warnings) are captured with zero customer, order or basket detail — just operational health.
Events go into a bounded local queue (cap 100 items) and retry every 5 minutes via WP-Cron, up to 5 attempts per event. A Monitrova outage can’t back up your database with thousands of pending rows.
The plugin is distributed directly from your Monitrova instance — build-on-demand, version-matched to the platform you’re sending to. That keeps client/server versions in lockstep and avoids the wp.org review backlog. The codebase passes Plugin Check cleanly so a wp.org listing is on the roadmap if there’s demand.
Start free for uptime, SSL and homepage health. Upgrade to Starter when you want the WordPress timeline that turns alerts into "here’s what changed".