I’ve been building a WordPress monitoring tool lately, so disclosure: I have a product in this space.

One design decision became pretty obvious once I started working through failure cases: the site can’t be the only source telling you whether the site is healthy.

A plugin can report useful things from inside WordPress — installed plugins, core version, heartbeat, update state, and so on.

But there are also situations where that signal is exactly what you can’t rely on.

If PHP dies with a critical error, the site is unavailable, or the monitoring plugin itself stops running, an internal check may simply stop reporting.

So I ended up treating internal and external monitoring as two separate signals.

The WordPress agent reports what it can see from inside the site.

Separately, an external worker checks the site over HTTP and looks at the actual response, including WordPress-specific failure signals such as critical-error pages.

That separation has been useful because the disagreement between the two signals can be more interesting than either one alone.

For example:

• Agent is reporting normally, but the external check is failing.
• External site is responding, but the Agent has gone silent.
• Both fail around the same time.

Those are three very different situations.

It sounds obvious when you compare it to traditional infrastructure monitoring, but I’ve noticed a lot of WordPress health tooling still depends heavily on the site reporting its own condition.

For people managing client sites, how are you handling this today?

Do you run external uptime monitoring alongside a WordPress management tool, or do you rely mostly on the WordPress-side agent?