What WooCommerce Uptime Checks Detect, and What They Miss

WooCommerce uptime checks are often pitched as if they see everything. They don't, and it's worth knowing that before you rely on them. An external monitor looks at your store from the outside, like a visitor who never buys anything. It catches many of the failures that stop sales, but it doesn't walk through the cart or pay.

Here's what these checks detect, which pages to watch, and what's out of reach.

How an external check sees your store

An external monitor requests a URL on your store over the internet and inspects the response: whether it arrives, with what status code, and what text it contains. It doesn't log in to WordPress or install a plugin. It also doesn't run JavaScript, so it sees the HTML your server sends, not what the browser renders afterward.

That's enough to catch many of the failures that actually take a store down.

What uptime checks catch

• The store doesn't respond or responds too slowly: the server is down, out of resources, or blocked.
• Server errors: 500, 502, or 503 responses, PHP's white screen, or a maintenance mode left on after an update.
• Pages that load but are broken: if you watch for a piece of text, such as the "Add to cart" button or a product name, the monitor notices when it disappears even though the page returns 200.
• Expiring certificates or domains, which take the store offline just like an outage.
• Scheduled jobs that stop running, if your system cron sends a heartbeat when it finishes.

Which pages to watch

Watching only the home page isn't enough. A store can have a perfect home page and a broken product page. A sensible set:

1. The home page, watching for text that only appears when it loads correctly.
2. A top-selling product page, watching for the purchase button text.
3. The cart page, which is usually excluded from caching and forces WordPress to do real work.
4. The store's public API, for example /wp-json/wc/store/v1/products, with an API monitor that expects a 200. If WordPress or the database is failing, the API usually fails too, even while the home page is served from cache.

One detail: with an empty cart, the checkout page usually redirects to the cart. A monitor requesting it won't see the checkout form, so it's not the best URL to watch.

The caching trap

Many stores serve the home page from a cache or CDN. That's great for speed, but it can hide an outage: the cache keeps serving the saved page while WordPress behind it is broken. That's why it's worth watching at least one URL that bypasses the cache, like the cart or the API.

What uptime checks miss

To avoid surprises:

• No test purchases. They don't add products to the cart, fill in checkout, or pay.
• No payment gateway visibility. A broken connection to your payment processor isn't visible from outside.
• No order emails or stock checks. They don't confirm that confirmation emails go out or inventory updates.
• No JavaScript-rendered content. If a button only appears after a script runs, the monitor won't see it.
• No logged-in areas, like My Account or the WordPress dashboard.
• No real-user experience. They measure the response our server gets, from a single location.

For those, you need something else: run a test purchase now and then, review orders and emails, and keep an eye on WooCommerce's logs.

Plugin vulnerabilities

Plenty of store outages start with a vulnerable plugin. On paid plans, the Domain Kit reviews WordPress and known vulnerabilities in the components visible from outside. That scan only runs on verified domains, ones you've proven belong to you or your client.

The bottom line

A well-configured external monitor tells you quickly when the store stops responding, throws errors, or loses what matters on the page. It won't tell you payments are coming in. Everything it can watch on a WordPress site is covered in WordPress uptime monitoring.

Frequently asked questions

Do uptime checks prove customers can buy?

No. They don't add products to the cart or pay. They can confirm the store responds and the purchase button still appears.

Will they catch a payment gateway failure?

No. A broken connection to your payment processor isn't visible from outside. Review orders or run a test purchase for that.

Which pages should I monitor?

The home page, a key product page, the cart, and the store's public API. That covers the most common failures without depending on a single page.

My home page is cached. Will the monitor notice if WordPress goes down?

Only if you also watch a URL that isn't served from cache, like the cart or the API. A cached home page can keep responding normally.

Do I need to install a plugin?

No. The monitor checks the store from the outside without installing anything.