Uptime monitors answer one question: does the page load? They do not answer the question that pays your bills: can a shopper still finish a purchase? A theme edit, an app update or a changed script can break add-to-cart or checkout overnight while every monitor stays green.
Here is the five-minute test I run, and what I check after every change.
The 5-minute manual test (do it on a phone-sized window)
- Open your store in an incognito window sized like a phone.
- Open a product that has variants. Pick a non-default variant, not the pre-selected one.
- Press Add to cart. Open the cart (the drawer and the
/cartpage) and confirm the variant, price and quantity are what you picked. - Press Checkout from both places.
- Confirm you land on a checkout page that actually shows shipping and payment options, not a blank or half-loaded page.
- Open the browser console (F12) at each step and look for red errors.
Do the same again after any theme edit, app install or update, shipping change or payment change. Three problems turn up again and again:
- Variant mismatch: a theme script and an app both write to the variant, so tapping "M" adds a different size or nothing.
- A third-party script blocks a button: upsell, countdown, bundle or popup apps on the cart drawer freeze the Checkout button or fail silently after an update.
- The hand-off to checkout: custom checkout apps or payment add-ons can work on desktop but break in a phone's in-app browser.
Shopify's own funnel report (sessions, added to cart, reached checkout, completed) is a good early warning if you look at it after each change. A sudden drop between steps is worth investigating the same day.
What automated checks can and cannot do
You can script this flow with a headless browser. It is worth doing, but be honest about the limits:
- A script that adds to cart through Shopify's cart endpoints can pass while a broken Add to cart button in your theme's own JavaScript fails real shoppers. Clicking the real button matters.
- Bot protection and sold-out products make a run inconclusive, not failed. Treat "could not check" as its own result.
- Stopping before payment means you have not proven that a gateway will capture or settle money. Test that with your gateway's own test mode.
Disclosure
I'm a student in Pune and I built a free checker called CartBeam that follows this path and keeps a screenshot of every step. It stops before address and payment and never places an order, and it goes through Shopify's own cart, so the manual test above still matters. You can try it on one public product link at https://cartbeam.infinityore.com. When I first ran it on 40 Indian stores, my initial scan showed 17 false alarms; fixing that classifier taught me more than the stores did.
What failure has bitten you? I would like to hear it.
Top comments (1)
"Could not check" as its own result is the line more people should steal. Most checkers silently map inconclusive to failed or, worse, to passed, and both lies cost you later - one in noise, one in confidence.
The failure that bit me hardest lives one layer up from yours: data, not code. A catalog CSV import that "succeeded" - valid file, valid rows, green dashboard - but mapped prices onto the wrong variant column, so every variant showed the base price. Every automated check passed because the checks validated the file, not the meaning. Your variant-mismatch failure is the same shape at runtime: two writers, one field, and the system reports success because success only meant "no error thrown."
The general rule I took from it: validate the thing the shopper sees, not the thing the pipeline reports. Your real-button click is that rule for code; for data it's reading the rendered price back from the storefront after import, not trusting the import summary.