WooCommerce monitoring: the shop is up, but can anyone buy?

The shop is up and selling nothing

A WooCommerce store can fail in ways a status check never sees. A theme update hides the add-to-cart button. A plugin conflict stops the cart from storing items. The payment gateway keys expire and checkout shows a generic error notice. Webhooks stop arriving and paid orders sit at "Pending payment". Every one of those returns a normal 200 on the home page, and the revenue loss is invisible until someone looks at the orders list. Monitoring a shop is mostly about choosing the pages whose content proves the pipeline works.

Which pages carry the signal

A practical shop set, each as its own monitor:

• Canary product page: a product that is always published and in stock, with "Add to cart" required. Edit the monitor if you ever retire that product.
• Cart page: an empty cart shows WooCommerce's "Your cart is currently empty" message, so requiring that phrase checks that the cart template renders; forbid the generic error notice too.
• Checkout page: Tenium cannot hold a cart across requests, so with an empty cart it will usually be redirected or shown a notice, which still proves the page and the theme load. Keep the expected status range broad (200-399) and require a phrase you see in that state.
• Store API: /wp-json/wc/store/v1/products?per_page=1 returns JSON on recent WooCommerce versions. A JSON API monitor with the path 0.id verifies that products are served from the database through the REST layer, independent of the cache.
• A search or category page, which exercises the database more than the cacheable home page.

Payment callbacks

Gateways notify the shop through a callback URL, often of the form /?wc-api=NAME, and the plugin's settings page shows the exact address. Tenium can only send a GET, and gateways POST signed payloads, so the response you get will usually be an error status of some kind. That is fine: set the expected status to 200-499, which passes any answer that proves PHP is running and fails a 500, 502, 503 or a timeout. What this does not show is whether the gateway can reach you or whether signatures validate, so keep an eye on the delivery log in the gateway's own dashboard as well.

Slow checkout is a cost

A checkout that takes eight seconds loses carts without ever going down. On Pro and Agency you can set a slow threshold in milliseconds, which compares the average of the last three checks with your number and opens a degraded incident when exceeded. Choose the value from your own data: let the monitor run for a week, read the response-time chart, and set the limit around double the usual figure. Remember that checks hit the uncached cart or checkout pages from several regions, so the figure includes network distance.

Scheduled sales, stock and the Action Scheduler

WooCommerce relies on its Action Scheduler for emails, subscriptions, stock reservations and scheduled sale prices. It runs on top of wp-cron, so the advice from WordPress monitoring applies doubly: run it from a system scheduler and attach a heartbeat. If WP-CLI and the Action Scheduler commands are installed, a job like wp action-scheduler run followed by a curl to the heartbeat tells you when the queue stops moving, usually before customers complain about missing confirmation emails.

Sizing, alerts and peak days

Count six to ten monitors per shop: canary product, cart, checkout, Store API, wp-login, callback, SSL / domain and a heartbeat. Starter's 100 monitors cover about 12 shops at eight each, Pro's 300 about 37. Route alerts to somewhere a person will notice: Telegram and Slack start on Starter, and Pro adds escalation if the first message is not acknowledged. Before a big promotion, shorten the interval on the key monitors (1 min on Starter, 30 s on Pro), and schedule maintenance windows for deploys so they do not eat the uptime figure the shop owner sees on the status page.