An online shop can pass every technical check and still take in not a single euro. The server answers with HTTP 200, the homepage loads, uptime monitoring shows solid green -- and yet no order arrives. The reason sits deeper in the buy funnel: a cart that does not store items, a coupon field that fails with an error, a payment gateway in timeout or an OTP step that loses the session. With an average cart abandonment of roughly 70 percent (Baymard Institute), a broken order path goes unnoticed without dedicated monitoring until revenue visibly collapses -- often hours or a full selling day later. Synthetic transaction monitoring closes this gap: it runs the complete buy funnel every minute from several regions and reports a silent failure before the revenue curve reveals it. How such checkout monitoring works, where it differs from pure uptime and log monitoring, and which alert thresholds make sense is the subject of this article.
The Green Check Lies: HTTP 200 Is Not Revenue
Uptime monitoring answers exactly one question: is the server reachable? For many outages that is the right question -- a total outage, a 500 error, an expired certificate are reliably detected. But an order path consists of a dozen steps that all have to work individually for an order to result. The web server can deliver every one of these steps with status code HTTP 200 and still fail on substance: the page loads, but the add-to-cart button triggers a JavaScript error. The payment form appears, but the connection to the gateway runs into a timeout. The green check in the uptime dashboard describes the wrapping, not the contents.
This is where the most dangerous failure type of all arises: the silent failure. It raises no alarm because, from the perspective of classic monitoring, everything is fine. The homepage is reachable, response times are normal, the logs show no server errors. Only nobody buys. The operator notices the problem only when the revenue curve stays conspicuously flat -- and even then the first assumption is often a weak sales day rather than a technical defect. In the worst case, hours pass in which every visitor fails at checkout without a single warning signal being triggered.
The most expensive outage is the one nobody sees
Where the Order Path Fails Silently
A modern order path is a chain of interdependent systems -- shop software, database, payment provider, shipping and tax logic, fraud checks and external interfaces. Each link can break on its own without visibly disturbing the rest. The following points fail most often in practice without a pure status-code check noticing anything:
Shopping cart
Items do not land in the cart, quantities jump back or the cart empties after a reload. Common causes: a broken session, a caching error or a JavaScript break after an update.
Coupon and discount logic
The discount or coupon field throws an error, rejects valid codes or blocks the continue button. Customers with a promo code -- often the most purchase-ready -- abandon exactly here.
Shipping and tax calculator
Shipping or tax is not calculated, shows a placeholder or a wrong total. Unexpected extra costs are the single most common abandonment reason at 39 percent (Baymard Institute).
Payment gateway
The connection to the payment provider runs into a timeout, the form does not load or the return after payment fails. The step where real money moves is also the most fragile.
OTP and 3-D Secure
The two-factor or 3-D Secure prompt loses the session, fails to load the confirmation window or does not return to the shop after approval. The purchase is authorised but never arrives.
Order completion
The order is placed, but the confirmation page does not appear, the confirmation email is missing or the order never reaches inventory. From the customer's view it is unclear whether they bought -- from the shop's view the revenue is missing.
The scale of these failure points is well documented. Among users who abandon checkout for a concrete reason, 15 percent (Baymard Institute) cite a website error or crash as the cause. A further 18 percent (Baymard Institute) fail because of a checkout process that is too long or too complicated, and 19 percent (Baymard Institute) because of a forced account creation. Missing payment methods cost 10 percent (Baymard Institute) of completions, a declined card another 8 percent (Baymard Institute). Each of these points can be aggravated by a technical defect -- and a defect sitting at exactly one of these already fragile spots acts like an accelerant on the abandonment rate.
Synthetic Transaction Monitoring: Replaying the Purchase
Synthetic transaction monitoring goes a decisive step beyond an HTTP check. Instead of just requesting a page, it replays a real purchase in an automated browser: open a product, add it to the cart, go to checkout, enter an address, choose a shipping method, select a payment method and reach the last step before the actual charge. This flow runs script-driven, every minute and from several geographic regions -- around the clock, including nights and weekends, when no human is watching the shop.
The difference lies in the validation. A pure status-code check is satisfied as soon as the server returns 200. A transaction check, by contrast, verifies the actual state after each step: did the item really land in the cart? Is the subtotal correct? Was shipping calculated? Does the provider's payment form appear? Only when every step delivers the expected result on substance is the buy funnel considered intact. This also detects partial outages where the server responds flawlessly on paper but the customer still does not reach the finish line.
So that such checks do not trigger real orders or real payments, they work with clearly marked test data and with sandbox or test endpoints of the payment page. The synthetic runs are excluded from real analytics so they distort neither revenue figures nor conversion rates. The following steps form the minimum scaffolding of a meaningful buy funnel:
- Product detail page: price, availability and the add-to-cart button load correctly and are operable.
- Cart: the chosen item is present in the right quantity, the subtotal is correct, a test coupon is applied correctly.
- Checkout: address and shipping selection work, shipping cost and tax are calculated and shown coherently.
- Payment: the provider's payment form loads in the sandbox, the payment-method selection and the 3-D Secure or OTP step are reachable.
- Completion: the order confirmation appears, an order number is issued and the test order is clearly marked as such.
- Response times: each step is additionally timed so that a gradual slowdown of individual funnel stages is noticed early.
Uptime, Log, Transaction -- Three Layers, One Picture
Transaction monitoring does not replace the established methods but closes their blind spots. Each of the three layers answers a different question, and only together do they give a complete picture of a shop's readiness to sell. Whoever runs only one layer always sees just one slice:
| Monitoring layer | Question checked | Reliably detects | Blind spot |
|---|---|---|---|
| Uptime monitoring | Is the server reachable? | Total outage, 5xx, timeout, certificate expiry | Functional errors at HTTP 200 (silent failure) |
| Log monitoring | Is the backend throwing errors? | Exceptions, rising error rates, suspicious patterns | Errors without a log entry, frontend and third-party failures |
| Transaction monitoring | Can a customer buy? | Broken cart, coupon, payment, OTP -- end to end | Needs carefully maintained check scenarios and test data |
The practical benefit shows in the interplay. Uptime monitoring detects the loud total outage in seconds, log monitoring makes backend errors and their clustering visible, and transaction monitoring is the only layer that confirms a customer can actually buy all the way to the last step. If an external payment script fails without the own server logging an error, that failure stays invisible to uptime and log monitoring -- while the synthetic purchase run trips over the broken step immediately.
Three questions that are not the same
Sensible Alert Thresholds Instead of Alarm Fatigue
Transaction monitoring is only as good as its alerting. Thresholds that are too sensitive produce a stream of false alarms until nobody looks anymore; thresholds that are too sluggish let real outages slip through. The target corridor sits in between -- an alarm should fire as soon as a real purchase reproducibly fails, and stay silent as long as only individual measurements fluctuate. The following rules have proven effective:
- Multiple confirmation instead of a single measurement: a step counts as broken only when it fails in at least two consecutive runs and from at least two regions. This filters out short-lived network blips.
- Step-level alarms: the alarm names the failed step (cart, payment, OTP) and the error type, not just check-red. This considerably shortens the time to the right diagnosis.
- Severity tiers: a broken payment step is critical and escalates immediately; a 40 percent higher response time in the cart is a warning that escalates only on a persistent trend.
- Business-hours weighting: during the evening peak and on promotional days the thresholds are tighter and escalation is faster, because that is when the most revenue is at stake.
- Deduplication: if a shared gateway fails, many checks go red at once. A professional setup bundles this into one incident instead of fifty individual alarms and thus prevents alarm fatigue.
- Recovery confirmation: an incident counts as resolved only when several complete purchase runs succeed again -- not already at the first green individual step.
Tie thresholds to your own buying pattern
What the Silent Failure Really Costs
The economic lever of checkout monitoring comes from two figures. First, an average of 70.22 percent (Baymard Institute) of all started orders are abandoned -- the order path is already the bottleneck where the most revenue is lost. An additional technical defect at exactly this point acts as a multiplier on an already fragile system. Second, through better checkout flows alone, large shops could raise their conversion by an average of 35.26 percent (Baymard Institute); extrapolated, that equals around 260 billion US dollars (Baymard Institute) of recoverable orders across US and EU shops. Keeping this funnel technically intact therefore defends the single most valuable stretch of the whole customer journey.
Even without a total outage, the functioning of the funnel decides revenue. The Deloitte study Milliseconds Make Millions shows that a mobile load-time improvement of just 0.1 seconds raises retail conversion by 8.4 percent (Deloitte, Milliseconds Make Millions) and the average order value by 9.2 percent (Deloitte, Milliseconds Make Millions). Speed has the greatest effect where purchase intent is highest: the transition from product detail page to cart improves by 9.1 percent (Deloitte, Milliseconds Make Millions). Monitoring that measures not only reachability but also the response time of every funnel step makes such creeping losses visible before they show up in the revenue curve. Anyone who has once worked through the cost of a shop outage quickly sees how small the running monitoring cost is by comparison.
A green uptime signal proves the door is open -- not that anyone at the till can take payment.
Checkout Checks as a Fixed Part of Maintenance
Checkout monitoring unfolds its value only as a maintained part of ongoing maintenance -- not as a script set up once that silently fails on a changed button after the next shop update. This is exactly the catch of synthetic purchase runs: they have to be updated with every relaunch, every theme change and every new payment method. As part of a maintenance contract, the check scenarios are maintained, the test orders are cleanly separated from real revenue and the alert thresholds are regularly adjusted to real buying behaviour.
In an emergency, the agreed response time is what counts. A detected checkout error is only worth as much as the speed at which someone fixes it -- which is why transaction monitoring and emergency support with a clear response time belong together. How to fix these times contractually is described in our article on response time in the SLA; how transaction checks complement pure uptime monitoring is the subject of a dedicated guide. For binding assurance, an SLA maintenance contract bundles monitoring, response times and responsibilities into a single document.
Two special cases deserve their own attention. Payment pages often embed external scripts whose silent manipulation is not immediately caught by uptime or functional checks -- why their integrity belongs under separate watch is described in our article on script monitoring for PCI DSS payment pages. And it is precisely under load that order paths tend to break: a load test for peak traffic reveals at what traffic level checkout tips over before the real campaign day does. Complementing this, continuous performance monitoring shows how the funnel's response times develop over weeks. This turns a collection of individual checks into a coherent monitoring system that protects revenue at its most sensitive point.
Sources and studies