WooCommerce Checkout Monitoring: An Uptime Check Cannot See This.

Short answer: proper woocommerce checkout monitoring means holding a session, putting a real product in the cart, and loading the checkout page. A monitor that requests the homepage, or even /checkout/ on an empty cart, will report a healthy store through an outage that stops every payment.

I wanted to know exactly how invisible this failure is, so I built a store and broke it on purpose.

The test

A WooCommerce install, one real product, a fatal error on the checkout template and nowhere else. That is not an exotic scenario. It is what a bad plugin update looks like on a Tuesday.

The store itself is ordinary. One product, published, purchasable:

archive, but a real product that a real customer could put in a basket.*

Then I probed it the way an external monitor does.

entire outage. So does one watching the shop page, and so does one watching the cart.*

Here is what that checkout page actually served:

customer to continue. Anybody who reached this point had already chosen to buy something.*

The store was up. The catalogue browsed fine. The cart worked with a product in it.

The business was down.

The trap in checking /checkout/

The obvious fix is to add the checkout URL to your monitor. It does not work, and this is the part I did not expect to be so clean.

the redirect, land on a 200, and record a pass. On this store, a checkout monitor configured the obvious way would have stayed green through the whole failure.*

A checkout check without a cart is a redirect check.

What WooCommerce checkout monitoring has to do instead

places an order every hour is easy. Walking to the payment step every day and never touching it is the useful version.*

Two details from building this that are easy to get wrong.

Assert on content, not status. A checkout page can return 200 and still be broken: no payment methods rendered, a JavaScript error that stops the place-order button, a shipping calculator that fails silently. Check that a payment method is actually present in the HTML.

This is the same lesson as reading a cache header: a status code describes the transport, not whether the thing the customer needs is on the page. Configuration and status both lie in the same direction, which is why the only checks worth trusting are the ones that observe behaviour.

Run it from outside, on a schedule you did not choose. A probe that only runs when you remember to run it is a probe that will be green the day it matters. Ours runs daily because the failure it catches is measured in trading hours, not in days.

Keep the session, then throw it away. The probe needs a cookie jar to hold the cart, and it needs to discard it afterwards, or you will fill your client’s reports with abandoned carts that were never real customers.

What to watch, in order of what it costs you

If you only add one check to a store, add the one that holds a cart and loads checkout.

After that, in the order I would add them:

• Payment methods present in the checkout HTML. Catches a gateway that stopped loading

while the page still returns 200.

• The cart total matches the product price. Catches tax and currency misconfiguration after

a settings change or a migration.

• Order rate against its own baseline. A store that normally takes 40 orders a day and has

taken 2 since 09:00 is telling you something no status code will.

• The add-to-cart path itself. If adding to cart fails, everything downstream reports fine

because nobody ever gets there.

Why stores get this wrong

Not carelessness. Checkout is the hardest thing on the site to monitor honestly, because testing it properly means simulating a customer, and simulating a customer badly means placing real orders in a real system.

So most agencies watch the homepage, which is trivial to check and tells you almost nothing about whether the store works. It is the cheapest check available, which is exactly why it is the one that gets set up, and exactly why it is the one that misses this.

There is a second reason, and it is the one I have more sympathy for. Checkout monitoring is work that only ever proves a negative. When it passes, there is nothing to show a client, so it competes for attention against work that produces something visible. That is the unbilled half hour again, in its most expensive form: the check nobody schedules, guarding the page that carries the revenue.

The gap between those two is measured in hours of lost trading, and it is the same shape as the scheduled jobs that quietly stop: no alert, no error anyone sees, and a customer eventually tells you.

This is what Till, Protuno’s eCommerce agent, is built to do. It walks one of your real products to the payment step every day and stops at the last screen before it charges. Being straight with you, as on every post here: Till is built and named but not live yet.

The free audit does check today, from the domain alone, whether a storefront is detected, whether the cart and checkout addresses answer, and whether they are being cached when they should not be. That last one costs real money on its own, and it is worth understanding separately.

If you look after a store, do the manual version this week. Add a product, load checkout, and look at it. Not the status code. The page.