Why checkout breaks silently — and how to catch it first

The worst outages don’t look like outages. The home page loads, the server answers 200 OK, every uptime check is green — and for the last four hours nobody has been able to pay.

You usually find out from a customer who took the trouble to write. Most don’t: they close the tab and buy somewhere else.

Why “the site is up” is the wrong question

An uptime check asks one thing: did the page answer? Checkout is not a page. It is a path — open a product, add it to the cart, open the cart, fill in an email, press a button — and every step depends on things a status code never sees:

• A JavaScript error. One TypeError in the cart script, and the “Checkout” button never renders. The HTML still arrives with 200.
• A renamed or moved button. A redesign changes “Checkout” to “Place order”. Nothing is broken on the server; the path is.
• A third-party script. The payment widget fails to load from its own CDN. Your server has no idea.
• Data, not code. An empty delivery zone, an expired coupon, a product with no price. The page renders; the step fails.

Each of these leaves your monitoring green and your revenue at zero.

Watch the path, not the page

The fix is to check checkout the way a visitor uses it: in a real browser, step by step, on a schedule.

With AxoWatch you record the path once. Open your site with the Chrome extension and click through it — every click and field becomes a step. From then on a real Chromium browser walks the same path every 6 hours by default, or every 15 minutes, every hour or once a day.

When a step fails, you don’t get “something is wrong”. You get the step:

🔴 Checkout is failing. It fails on: Click “Checkout”.

Don’t wake anyone for a one-off

Browsers are noisy. A slow CDN, a cookie banner that appeared late, a deploy in the middle of a run — any of them can fail a single run without anything being broken.

So a red run is never an alert on its own. AxoWatch runs the flow again right away. Only if the second run fails on the same path does the flow count as broken, and only then does a message go out — one message when it breaks, and one when it passes again. No repeats in between.

See what the visitor saw

A failed step comes with evidence, not a guess:

• A screenshot after every step, so you see the page as the browser saw it — the missing button, the error banner, the empty cart.
• How long each step took, so a step that went from 0.8 s to 9 s stands out before it times out.
• The error behind it. If your app reports errors to AxoWatch, the errors thrown during that run are tied to that run and that step — not matched by time.

That last one is usually the answer. “Click ‘Checkout’ failed” plus TypeError: cart.items is undefined on the same step is a bug report you can fix in minutes.

When the site changes, the flow shouldn’t break

Recorded tests have a reputation for being brittle: rename a button and the test fails forever. AxoWatch treats that as a change to adapt to, not an outage. When a step’s target moved or got renamed, the step is repaired and checked by a control run before the change is kept — and you can put it back with one click if you disagree.

Where to start

Pick the one path that earns you money. For a shop it is checkout, for a SaaS it is sign-up, for a clinic it is booking. Record it up to the last step before payment — or use a test account and a test card if you want the whole way. That single flow catches more real breakages than a dozen uptime checks on the home page.