WordPress

WordPress monitoring: crashes, failed emails, WP-Cron and a version inventory, reported by one plugin

MySentry Monitor is a free plugin that connects a WordPress site to MySentry in about two minutes. It reports fatal errors, JavaScript errors in visitors’ browsers, failed wp_mail() sends, an hourly scheduler heartbeat and a read-only version inventory — core, plugins and themes, with how long each update has been waiting. Reports go out at the end of the request — after the page has been handed to the visitor on PHP-FPM and LiteSpeed hosting — and nothing runs until you paste in a reporting URL.

Download MySentry Monitor 1.7.3 (zip)Free, GPL-licensed. Requires WordPress 5.8+ and PHP 7.4+. How to install

Install in four steps

  1. In the MySentry panel, add the website. It gives you two reporting URLs, each shown once (only a hash is stored): a server URL, which stays inside WordPress, and a page URL, which is printed into your pages and can only report browser errors and page views.
  2. Download the plugin and upload the zip in WordPress (Plugins → Add New → Upload Plugin), then activate it.
  3. Open Settings → MySentry, paste both URLs, save. The plugin asks MySentry which kind of token each one is, and refuses a server token in the page field — that field is readable by every visitor. Add your site’s address to the website’s allowed origins so browser errors and analytics are accepted.
  4. Press Send test. It checks both tokens and sends a test event, a heartbeat and the inventory, then shows what MySentry answered to each — so a refused heartbeat cannot hide behind an accepted test event.

Download MySentry Monitor 1.7.3 (zip). Requires WordPress 5.8+ and PHP 7.4+. GPL-licensed.

What it reports

wp.php.fatal

Fatal errors and uncaught exceptions — the white screen of death — caught by a shutdown handler, with the request URL and PHP version.

wp.php.warning

PHP warnings (E_WARNING), optional: switch the reporting level to “all” when you are chasing a problem, back to fatals only when you are not.

wp.client

JavaScript errors in your visitors’ browsers, with the page URL and browser — including errors thrown while the page is still loading. Capped at 10 per page view and de-duplicated.

email.wp_mail

Every failed wp_mail() send — contact forms, WooCommerce order emails, password resets — feeding the failed-email burst alert.

heartbeat

A WP-Cron heartbeat every hour (or twice daily, or daily), so a site whose scheduler has stopped is reported within your threshold.

wp.inventory

A read-only version inventory: core, plugins and themes with versions, activations and available updates — once a day and after every change. New in plugin 1.5.

analytics

Optional, off by default: the cookieless page-view beacon — page views, unique visitors, time on page, countries, referrers.

Designed never to slow your site

  • Error reports wait until the end of the request. On PHP-FPM and LiteSpeed hosting the page is handed to the visitor first; elsewhere the sends are capped at a few seconds per request.
  • Identical errors are suppressed locally for 15 minutes before another report is sent.
  • The heartbeat and the inventory are sent from WP-Cron, never during a visitor’s request.
  • Browser reporting is capped at 10 errors per page view and de-duplicated.
  • Empty fields are omitted from the payload; the plugin tolerates an unreachable server.
  • Nothing runs until a reporting URL is configured — an installed but unconfigured plugin is inert.

Version inventory: see the update that has waited 40 days

From plugin 1.5, the panel's WordPress tab shows the site's full version inventory: core, every plugin and theme, PHP, and — front and centre — every available update with how many days it has been waiting(amber from a week, red from a month). Across many sites, that ageing number is the thing nobody can see today without logging into each wp-admin in turn.

Version changes land in the site's change feed alongside everything else: a plugin updated, activated or removed is an entry with before and after, on the same tamper-evident timeline as redirects, headers and content.

The plugin is read-only by design: it reports state and cannot install, update, or change anything. There is no write path to your site — not in the plugin, not in the service.

Updates: plan, do it yourself, get it verified

Every waiting update in the panel has a Plan update button. The plan records the versions and a precheck (a fresh backup, confirmed by you); then you run the update in your own wp-admin, exactly as you do now. When the next inventory report arrives with the target version, MySentry verifies the outcome independently — site up, content present, no burst of new errors — and records it as succeeded, with the verification on the same evidence timeline. If it went wrong, one click records the failure or rollback, so the history is honest.

Caching, builders, WooCommerce

The plugin works with any theme and any page builder. Fully cached pages are served without running PHP, so PHP errors are captured on the requests that do run it — the admin area, checkout and cart, form submissions, logged-in visitors and cron — while JavaScript errors and analytics are captured on cached pages too. WooCommerce order emails go through wp_mail(), so a broken mail provider shows up as an email-burst alert rather than as a customer complaint a week later.

Heartbeat settings

Choose the pulse frequency (hourly, twice daily, daily) in the plugin. On a site that runs WordPress’s scheduler from a system cron the pulse is punctual, so the plugin tells MySentry how often it runs and MySentry decides when a silence is too long. Ordinary WP-Cron only runs when someone visits, so a quiet night can delay an hourly pulse by hours; there the plugin announces no schedule it cannot keep, and the allowance stays in the panel (it defaults to 26 hours — three hours suits an hourly pulse). The plugin can also own the threshold: switch on “Alarm after” and it is sent with every heartbeat, which is handy when you manage many sites and want one setting in the plugin rather than one per panel.

Agencies: one plugin, many sites

Each client site gets its own project in MySentry, its own pair of reporting URLs and its own allowed origins, so keys cannot be mixed up and a client site can be removed without touching the others. The panel’s overview shows every site’s live chart on one screen. See pricing for the 20- and 50-site plans. A staging copy of a client site stays quiet: the plugin remembers the address it was set up on, so a clone cannot keep a dead production cron looking alive or flip the production change feed back and forth.

WordPress questions

What is the ‘failed email burst’ alert?

When three or more email sends fail within ten minutes — a contact form, order confirmations, password resets — MySentry sends one alert about a probable mail outage (provider, DNS, an expired API key). This is the failure that quietly loses enquiries for days: the form says ‘sent’, nothing arrives.

How do I connect a WordPress site?

Create the website in the MySentry panel and copy its two reporting URLs — the server URL and the page URL; install the MySentry Monitor plugin and paste both into Settings → MySentry; add your site’s address to the allowed origins in the panel so browser errors and analytics are accepted; press ‘Send test’, which shows what MySentry answered to each part. The whole thing takes about two minutes.

What does the WordPress plugin report?

PHP fatal errors and uncaught exceptions (the white screen of death), optionally PHP warnings, JavaScript errors in visitors’ browsers, failed wp_mail() sends (contact forms, WooCommerce emails), an hourly WP-Cron heartbeat, a read-only version inventory of core, plugins and themes, and — if you switch it on — privacy-first page analytics. Every error carries the page address (without its query string), the PHP version and the request method.

Will the plugin slow down my site?

No. Error reports wait until the end of the request — on PHP-FPM and LiteSpeed hosting the page is handed to the visitor first — and repeated identical errors are suppressed locally for 15 minutes before they are sent at all. The heartbeat and the version inventory are sent from WP-Cron, never during a visit. Browser reporting is capped at 10 errors per page view. The plugin does nothing until a reporting URL is configured.

Does it work with caching plugins and page builders?

Yes, with any theme or builder. One nuance: a fully cached page is served without running PHP, so PHP errors are captured on the requests that do run it — the admin area, checkout, form submissions, logged-in visitors and cron — while JavaScript errors and analytics are captured on cached pages too.

My site uses a system cron instead of WP-Cron. Does the heartbeat still work?

Yes, and it is better. The heartbeat is a scheduled WordPress event, so it runs whenever WordPress’s scheduled events run. With a system cron (DISABLE_WP_CRON) the pulse is on time, so the plugin tells MySentry how often it runs and MySentry decides when a silence is too long — nothing to set. With ordinary WP-Cron, which runs only when someone visits, set the allowed silence in the panel (about three hours for an hourly pulse).

Which WordPress and PHP versions are supported?

WordPress 5.8 or newer and PHP 7.4 or newer. The plugin is GPL-licensed and installed by uploading the zip (downloadable from the WordPress page and from the panel); it is not yet listed in the WordPress.org directory.

Connect your WordPress site in two minutes

Free trial, no card required. Connect a site in two minutes.