The worst outage a shop has is the one that doesn’t look like an outage. The homepage loads, the phone doesn’t ring, and the orders quietly stop. Uptime can’t see that — so on the stores we host we watch the buying path itself: the catalogue, the cart, whether a payment method is still being offered, and the checkout page. Every five minutes.
We load your shop page and confirm it came back as a working WooCommerce page — not a theme error, not a white screen, not a 500.
We ask your store for one product through WooCommerce’s own Store API and confirm a real product comes back. This is the check that catches a database or plugin failure behind a shop page that still renders — and it tells us how many products your store is currently publishing.
We ask your store for a cart and read the payment methods it says are available. If that list is empty, nobody can pay you — a lapsed gateway, an expired API key, a plugin conflict — and that is a failure even though every page on the site loads perfectly. It works with whichever gateway you use; we read what your store offers rather than testing a particular provider.
We load your checkout URL and confirm it resolves instead of falling over. This is the weakest of the four checks and we’d rather say so than dress it up: on an empty cart WooCommerce correctly sends checkout to the cart page, so what this proves is that the route is alive and hasn’t fatalled — proving a payment form renders would need items in a cart, which would mean mutating your store.
A single failure is recorded and nothing more. We act on the second consecutive failure, five minutes later — because a monitor that shouts at every momentary hiccup is a monitor people learn to ignore, and then it’s worth nothing on the day it matters.
Every check is a plain page load. We never add anything to a cart, never submit a checkout, and never create a test order. Your reports stay clean, your inventory stays untouched, and monitoring never adds load to the one page you cannot afford to slow down.
A Store tab that answers one question — “is the shop working?” — before it shows you anything else.
Checkout is failing — the site itself is online, so uptime looks fine.
| Check | Result | Detail |
|---|---|---|
| Product catalogue | Checked 2 min ago | |
| Products from the database | Checked 2 min ago | |
| Cart and payment method | Checked 2 min ago | |
| Checkout | Checkout returned a server error · failing for 11 min |
Each check stands on its own and we never let one speak for another. A broken catalogue does not mean nobody can buy; a checkout route that has fallen over does not mean your products are gone. That is why the dashboard and the alert name the step that failed instead of announcing that “your store is down”.
The honest limit, stated plainly: none of this proves a card can be charged. Proving that would mean putting a real payment through your live store, and we will not do that to your orders, your inventory, or your reports. What these checks do prove is that the pages a customer needs are answering, that your products are reachable from the database, and that your store is still offering a way to pay — which is where a broken shop almost always breaks first.
Store checks are turned on per site rather than guessed at, and every path is tested before it is saved, so a mis-typed URL can never become a recurring false alarm. When a store check fails, the alert goes to us — the people who can actually fix it — and the failure appears on your dashboard the moment we see it.