BD Uptime Monitor vs Jetpack Monitor: self-pinging plugin vs Automattic’s external monitor

Jetpack Monitor is an external uptime check run by Automattic — they ping your site from their infrastructure and email you if it goes down. BD Uptime Monitor runs in WordPress itself, pings its own REST endpoint via cron, and alerts on failure. These are technically different approaches to the same problem, with real tradeoffs.

Pick BD Uptime Monitor if…

Pick BD if you want uptime checks under your own control, no external dependency on Automattic, and one license dashboard with the rest of BD.

Pick Jetpack Monitor if…

Pick Jetpack Monitor if you want truly external monitoring (caught when your whole server is offline), and you're already running Jetpack.

Switching from Jetpack Monitor?

Expect to lose true external monitoring (a self-pinging monitor can't detect its own server being completely offline) and gain control + REST health endpoint + bundle pricing.

Feature comparison

FeatureBD Uptime MonitorJetpack Monitor
Where the check runs sourceOn your own WordPress install (self-ping via REST)On Automattic's external infrastructure
Detects total server outageNo u2014 if WP-Cron can't run, no alert firesYes u2014 external pings catch full outages
Check frequencyConfigurable (5/10/15 min via cron)Every 5 minutes
Email alertsYes u2014 on down + recoveryYes u2014 on down + recovery
SMS / push alertsNo u2014 email onlyPush notifications via Jetpack mobile app
REST health endpointYes u2014 `/wp-json/bdum/v1/health`No u2014 closed system
Incident history / logsYes u2014 local DB tablesYes u2014 in WordPress.com dashboard
Multi-site managementPer-license per-siteAll Jetpack-connected sites in one dashboard
Requires WordPress.com accountNoYes u2014 Jetpack connection required
Data leaves your serverNoYes u2014 site status reported to Automattic

Pricing — 3-site agency, annual

PlanBD Uptime MonitorJetpack Monitor
Free / 1 siteNot free u2014 $49/yrFree (basic monitor)
Starter / 1 site$49/yr$239/yr (Jetpack Security includes monitor)
Agency / unlimited$199/yrPer-site Jetpack licenses

When to pick which

Pick Jetpack Monitor — specifically the free tier — if you want a basic uptime check and don't want to pay anything. It's free, it's external (which is the right architecture for uptime monitoring), and it works. We're not going to pretend otherwise. If you're already running Jetpack for any other reason, the included monitor is fine and there's no reason to pay for ours.

Pick BD Uptime Monitor if you specifically don't want a Jetpack/WordPress.com connection, you want incident history stored locally in your own database, you want a REST health endpoint your own systems can poll, and you want a single license dashboard with the rest of the BD plugin set. The honest architectural caveat: a self-pinging monitor cannot detect its own server being completely offline. If WordPress can't run, neither can the monitor that's supposed to alert you that WordPress can't run. We mitigate this with a configurable health endpoint that external services (UptimeRobot free tier, your own monitoring) can poll — but the canonical answer for "what if my whole server dies" is "use external monitoring as well."

The honest comparison: for pure uptime monitoring, an external service is architecturally correct and a self-pinging plugin isn't. Jetpack Monitor's free tier gets that right. BD Uptime Monitor exists for operators who want incident logging and health endpoints inside WordPress, with no external account, as part of a bundle — not because we think we beat Jetpack on the monitoring problem itself.

Migrate from Jetpack Monitor to BD Uptime Monitor

1. Keep Jetpack Monitor active during the migration — don't leave yourself without monitoring during cutover.
2. Install BD Uptime Monitor, activate the license, and configure the alert email.
3. Set the check interval (5 min is the most aggressive option) and confirm WP-Cron is firing reliably.
4. Hit the `/wp-json/bdum/v1/health` endpoint manually to confirm it returns 200 and a JSON status payload.
5. (Recommended) Set up an external poll of the REST health endpoint via UptimeRobot's free tier as a backstop — this covers the "whole server down" case BD can't detect on its own.
6. Verify both monitors fire alerts independently for a manufactured downtime test (e.g., put the site in maintenance mode briefly).
7. Disconnect Jetpack Monitor only after BD has run for at least one full week without false positives.

FAQ

If BD pings itself, what happens when my server goes down?

Nothing u2014 and that's the architectural limitation we're upfront about. WP-Cron can't run if WordPress can't run. The mitigation is BD's REST health endpoint, which an external service like UptimeRobot's free tier can poll independently.

Why pay for BD when Jetpack Monitor is free?

You shouldn't, if Jetpack Monitor's tradeoffs are acceptable to you. BD makes sense if you're already buying other BD plugins, want local incident logging, don't want a WordPress.com connection, or want a REST health endpoint to integrate with other systems.

Does BD support SMS alerts?

No u2014 email only in v1.0.0. Jetpack's mobile app supports push notifications. If SMS is critical, use a tool like Pushover via webhook or pair BD with an external service that does SMS.

Can I run both monitors at once?

Yes, and we recommend it during migration. Long-term, running BD plus an external check (Jetpack free, UptimeRobot free, or your host's monitor) is actually a sensible layered setup.

What's the REST health endpoint for?

External monitoring tools (or your own scripts) can poll `GET /wp-json/bdum/v1/health` and get JSON back: site up, DB connection, recent error count. It's how you turn a self-pinging plugin into something an external watchdog can verify.

Try BD Uptime Monitor → Or grab a bundle

# BD Uptime Monitor vs Jetpack Monitor

Uptime monitoring has a fundamental architectural rule: the monitor should not be on the same machine as the thing it monitors. If your server goes down, anything running on it goes down too — including the script that’s supposed to email you about the outage. Jetpack Monitor follows this rule correctly: Automattic’s infrastructure pings your site every five minutes from outside, and emails you if the response fails. BD Uptime Monitor doesn’t follow this rule. It runs in WordPress, pings its own REST endpoint via WP-Cron, and logs incidents to a local database table.

We’re going to be honest about that gap before we sell you anything else. If your server is completely offline, BD Uptime Monitor can’t tell you. The cron job that fires the check can’t run if PHP can’t run, and the email that should fire when the check fails won’t send if the mail process can’t start. It’s a self-pinging monitor and it has the limitations a self-pinging monitor has.

So why does BD Uptime Monitor exist? Because not every operator wants a Jetpack/WordPress.com connection on their site, and not every operator wants their uptime data reported to Automattic. The plugin solves a slightly different problem: it logs detailed incident history into your own database, it exposes a REST health endpoint at `/wp-json/bdum/v1/health` that external tools can poll independently, and it bundles cleanly with the rest of the BD plugin set under one license dashboard. The intended pattern is BD Uptime Monitor for in-WordPress incident logging plus an external watchdog (UptimeRobot’s free tier, your host’s monitor, or yes, Jetpack Monitor’s free tier) hitting the health endpoint as a backstop for full-outage detection.

Where Jetpack Monitor wins clearly: it’s free at the basic tier, the architecture is right, and the WordPress.com mobile app pushes notifications in addition to email. If you’re already running Jetpack and the basic monitor’s check frequency is enough, you have no reason to pay for ours.

Where BD wins narrowly: no Jetpack connection, no WordPress.com account, local incident database (auditable, exportable), the REST health endpoint for integration with external systems, and the bundle pricing if you’re already paying for BD Security or BD Backup. The plugin is also much smaller — it’s one menu, two tabs, and a settings table. It doesn’t drag along Jetpack’s broader feature set.

Honest summary: for pure uptime monitoring, the right answer is an external service, and Jetpack Monitor’s free tier is one of the best free options available. BD Uptime Monitor is for operators who want incident logging inside WordPress and a health endpoint they can poll from elsewhere — and who already use BD plugins. We’re not pitching this as “better than Jetpack”; we’re pitching it as a different shape of tool that fits different setups.