A shop that looks open and cannot take a payment is the expensive kind of down

The arithmetic of a quiet outage

Take a shop with an average order of $60 and four orders an hour in the evening. A broken checkout that nobody notices for 3 hours loses about $720 in orders, and some of those customers will not come back. A home page monitor would have said all was well for the whole period, because the home page was fine. The money was lost further down the funnel, and that is where the monitoring has to go.

The good news is that most shop failures leave fingerprints that a plain request can read. This page walks through the path an order takes, and what to check at each step.

Step by step along the funnel

1. A canary product page. Pick one product that is always published and in stock. Require the text on its add-to-cart button, and forbid your out-of-stock and generic error strings. A theme or plugin update that breaks the button is caught on the next check.
2. The cart. Request the cart URL and require a phrase that only a correctly rendered cart contains. Empty carts still render, which is what you want from an unauthenticated check.
3. The checkout. Same idea: a phrase from the form, and a forbidden string for the notice your platform shows when it hits an error. Checkout is where payment scripts, shipping rate lookups and tax services all meet, so it breaks more often than other pages.
4. The payment callback. Gateways confirm payments by calling your shop. If that URL starts returning errors, customers pay and orders never turn from pending to paid. Monitor the callback endpoint with a wide accepted-status range such as 200 to 499, so only server errors and timeouts alert.
5. Search and category pages. Often served by a different backend or index. A quick keyword check on a category page catches a dead search service.

Detailed configuration for WooCommerce sits on the WooCommerce monitoring page; the same pattern works for any platform with predictable page text, and the keyword monitoring page explains the rules.

SSL expiry before the busy season

Certificate expiry is the only outage that arrives on a known date, which makes it the most embarrassing. A certificate issued for a year or renewed by an automated job that stopped running will expire on a schedule you could have read in advance. The risk is highest before Black Friday, when nobody wants to touch anything and the renewal job has been silently failing since the server move in the summer. Add an SSL monitor for the shop and for the payment and CDN subdomains, and a domain expiry monitor for the registration. The warnings start a month ahead, and the expired-certificate runbook is ready if you are already past that point.

Alerts that reach someone during a sale

Where the alert goes matters as much as what triggers it. On Starter you get Slack and Telegram; Telegram messages carry an acknowledge button, which is useful when two people share the duty. On Pro ($29) escalation policies move an unacknowledged incident to a second Telegram or email contact after the delay you set. Checks run as often as every 30 s, so a broken checkout is confirmed in about a minute rather than five.

Pair monitoring with a public status page on your own domain, so customers who worry can see the shop is being looked at, and use maintenance windows for planned updates outside trading hours. Agencies running several shops can put each in its own workspace on the Agency plan ($59); see the agency offer.

Where this stops

An uptime monitor cannot tell you the payment provider declined a card, that stock counts drifted, or that a discount code is applying the wrong amount. It also does not drive a browser, so a failure that appears only after JavaScript runs may pass the check. Treat these monitors as the first line: they tell you the shop is open and each step responds, and your order dashboard remains the source of truth for revenue.