To monitor WooCommerce uptime properly, do not watch the store as a single URL. Set up separate checks on the homepage, a product page, the cart and the checkout, each with a content assertion on text that only renders when that page works. A WooCommerce store can return a perfect 200 on the homepage while the add-to-cart button is dead, the checkout throws a payment error, or a product page shows “out of stock” on everything. Monitoring only the homepage misses every one of those, and those are the failures that stop money coming in.
The reason is the same one that trips up all WordPress monitoring: a broken page still answers. A JavaScript error on the cart, a failed payment gateway, or a plugin conflict on checkout does not return a 500. It returns a 200 with a page that no longer sells anything. Here is how to watch the paths that actually take an order.
The four paths worth monitoring separately
| Path | Check for | What it catches |
|---|---|---|
| Homepage | Your store name or a header string | The white screen, a fatal error, the whole site down |
| A product page | The product title and an “Add to cart” label | A broken template, a catalog that failed to load, a missing button |
| The cart | A cart-specific string like “Proceed to checkout” | A JavaScript or AJAX error that empties or breaks the cart |
| The checkout | A checkout field label or the order button text | A payment plugin conflict, a gateway timeout, a broken form |
You do not need a full scripted transaction that adds a product and pays for it to get most of this value. Four simple HTTP checks with the right keyword on each will catch the large majority of real WooCommerce failures, and they run every 30 seconds without a browser or a test card.
Set up each check
Homepage as the baseline
Add an HTTP check on your store's home URL and assert on a string that always renders when the site is healthy, such as your store name in the header or a category menu label. Set the interval to 30 or 60 seconds. This is your catch-all for the site being fully down or serving a blank page after a plugin update.
Product page for the catalog
Pick a stable, always-available product and check its page. Assert on the product title plus the “Add to cart” button text. If a theme update breaks the product template, or the catalog fails to load from the database, the button text vanishes and the check fails, even though the URL still returns 200.
Cart and checkout where the money is
The cart and checkout are the pages most likely to break on their own, because they carry the most plugins: payment gateways, tax and shipping calculators, and conversion scripts. Check each one and assert on text that only appears when the page is functional, like “Proceed to checkout” on the cart and the place-order button label on checkout. When a payment plugin update conflicts with the theme and the order button disappears, you find out in under a minute instead of from Monday's sales report.
alertping
Know your checkout is broken before your customers do
Watch the homepage, product, cart and checkout as separate checks with content assertions. 30-second checks, SMS included, no plugin on your store.
Add SSL and a cron heartbeat
Two more checks round out a store's monitoring. First, watch the SSL certificate expiry: an expired certificate on a store means every visitor hits a browser security warning before they can buy, and it is completely preventable with a 30-day warning. Second, if your store runs scheduled jobs, order exports, inventory syncs, abandoned-cart emails, add a cron heartbeat so you know when one of those quietly stops. A backup or an inventory sync that dies is invisible until the day you need it.
Why external monitoring beats a plugin for a store
It is tempting to install a monitoring plugin, but for a WooCommerce store that is the wrong tool for uptime. A plugin runs inside WordPress, so when the site goes down the plugin goes down with it and cannot alert you. It also adds load to every request, which is the last thing a store under traffic needs. External monitoring runs on separate servers, checks your pages the way a real shopper's browser would, and keeps working precisely when your site does not. The full case is in WordPress uptime monitoring, and it applies double to a store where downtime has a dollar figure.
What good looks like
A well-monitored WooCommerce store has four to six checks running every 30 seconds: homepage, a product page, cart, checkout, SSL expiry and a cron heartbeat, each with an assertion on real page content, confirmed from more than one region, alerting to SMS and Slack. Set up that way, the failure that used to cost you a weekend of lost orders becomes a text message you act on while the store is still busy. That exact set of checks comes preconfigured with WooCommerce uptime monitoring. If you run several stores for clients, the same setup scales through uptime monitoring for agencies, with every store on one dashboard.