What breaks in e-commerce checkouts: data from 55,000 test purchases

The headline numbers

About 1.2% of all test purchases failed (635 of roughly 55,000). That sounds small until you spread it out: 60 of the 89 stores, two in three, failed at least once in seven weeks. Checkout failures are not rare events on unlucky stores; they are a normal part of running one.

For the stores with full incident tracking (177 checkout incidents on 20 stores), the median incident lasted 35 minutes. One in ten lasted three hours or more. A store doing a few orders an hour loses real money in either case, and nobody had told the owner yet.

Most failures happen while the site is up

We grouped the 121 incidents with a clear cause by the step where the purchase stopped. Only 23% were the site being down or slow: server errors, timeouts, an unreachable store. The other 77% happened while the homepage loaded normally and any uptime monitor would have shown green.

The checkout step itself was the largest group at 33%: forms that would not submit, sessions that were lost between steps, scripts that broke the page. Then products that could not be bought or had disappeared (16%), cart problems such as add to cart failing or a price that changed in the cart (12%), shipping with no methods offered or one that could not be selected (11%), and payment or order placement (5%).

This is the core reason we built a real-browser monitor. A 200 response says a page answered. It says nothing about whether a customer can get from a product to a placed order. See why uptime monitoring misses broken checkouts for the longer argument.

When it breaks: nights, and after changes

A third of incidents (32%) started between 22:00 and 03:00 Athens time, a five-hour window that is about a fifth of the day. That is when deploys, cron jobs, indexers, imports and backups tend to run, and when nobody is looking at the store. Weekdays and weekends were roughly even; failures do not wait for office hours.

Some failures are short and some sit for hours. Price mismatches between product page and cart had a median incident length of about three hours, longer than any other common type, because the store looks fine and the cart still works; it just charges the wrong amount. Related: Magento cron and indexers and updating WooCommerce plugins safely.

Even passing checkouts are noisy

In 88% of the checkouts that succeeded, the browser console logged at least one JavaScript error along the way. Most are harmless: a tracking script, a blocked font, a deprecated call. That is exactly the problem. When every checkout has errors, an error count alone cannot tell you the checkout broke, so alerts based on console errors become noise that people learn to ignore.

What works is checking outcomes, not symptoms: did the cart hold the right product at the right price, were shipping methods offered, is a payment method ready. A typical full test purchase took about 28 seconds from product page to payment step. More on keeping alerts meaningful in alert fatigue in checkout monitoring.

How we measured, and the limits

The sample is 89 live stores, mostly Magento 2 with Luma, Hyvä and one-step checkouts, plus WooCommerce, in Europe. Each was checked every 5 to 30 minutes. A run counts as failed when the purchase could not continue and the monitor knew why; runs where the monitor could not tell (a bot wall, a minimum order amount, an inconclusive page) are excluded. Incident durations come from the 20 stores where incidents were tracked end to end.

Our failure detection improved during the period, and a small share of early failures were later classed as monitor mistakes, so treat the exact percentages as approximate. No store, product or customer data is named or published here. You are welcome to cite these figures with a link to this page.

Want to know which group your store falls into? Run the free Magento checkout test or the WooCommerce checkout checker: it walks your checkout in a real browser and shows the step where it stops.