The downtime everyone watches, and the one nobody sees
When your site goes down, Datadog rings. StatusPage turns red. The tech team is on deck within minutes. That scenario is covered.
But there's another kind of downtime, far more frequent and far more expensive over time: the checkout micro-outage. The server responds 200 OK. The page displays. But the "Pay" button does nothing when you click it. Or the Stripe API times out after 15 seconds. Or a JavaScript error stops the card form from loading.
For your backend monitoring, everything is fine. For your revenue, it's a silent hemorrhage.
The real cost: €10,000 per minute
The e-commerce industry puts the average cost of downtime at €10,000 per minute for a mid-market site. That figure includes direct lost revenue, the impact on running paid campaigns and the cost of recovering abandoned carts.
For a site doing €500,000 a month:
| Downtime duration | Estimated lost revenue | Wasted paid budget | Total cost |
|---|---|---|---|
| 5 minutes | €580 | €120 | €700 |
| 15 minutes | €1,740 | €350 | €2,090 |
| 30 minutes | €3,470 | €700 | €4,170 |
| 1 hour | €6,940 | €1,400 | €8,340 |
| 3 hours | €20,830 | €4,200 | €25,030 |
For a bigger site, doing €2,000,000 a month:
| Downtime duration | Estimated lost revenue | Wasted paid budget | Total cost |
|---|---|---|---|
| 5 minutes | €2,310 | €350 | €2,660 |
| 15 minutes | €6,940 | €1,050 | €7,990 |
| 30 minutes | €13,890 | €2,100 | €15,990 |
| 1 hour | €27,780 | €4,200 | €31,980 |
| 3 hours | €83,330 | €12,600 | €95,930 |
And those are only the direct costs. Indirect costs (customers lost for good, negative reviews, SEO impact) aren't counted.
77% won't come back
The most important figure is this one: 77% of consumers abandon a site for good after hitting an error during checkout (Loqate/GBG 2024 study).
They leave the site, not just their cart. They go to a competitor and have no reason to come back, and customers who hit a checkout bug are 3 times more likely to switch to a competitor within 30 days.
A 20-minute checkout micro-outage on a Tuesday afternoon doesn't make headlines. But the 150 customers who saw an error message at the moment of payment remember it.
Micro-outages: frequent and invisible
Full outages (site unreachable, 500 error) are rare (1 to 2 times a year for a well-run site). Checkout micro-outages are a different story:
- Average frequency: 2 to 5 times a month
- Average duration: 5 to 30 minutes
- Main causes: client-side JavaScript error, payment API timeout, third-party script conflict, component update that breaks the form
An average e-commerce site suffers 60 to 150 minutes of checkout micro-outage a month. On a site doing €500,000 a month, that's between €7,000 and €17,000 in monthly losses, without anyone knowing.
Why standard monitoring doesn't see them
Your monitoring stack is probably set up to watch:
- The server: response time, HTTP error rate (Datadog, New Relic)
- Application errors: Python/Node/PHP exceptions (Sentry, Bugsnag)
- Availability: HTTP ping every 60 seconds (UptimeRobot, Pingdom)
None of these tools watches what happens in the user's browser. If the "Pay" button stops responding because of a JavaScript conflict, the server keeps responding 200 OK. Sentry doesn't see the error if it's client-side and uncaught. UptimeRobot confirms the site is online.
The result: traffic keeps coming in (you pay for the clicks), users reach checkout (they browsed normally), but nobody buys for 20 minutes, and nobody knows.
The warning sign: purchases stop
The most reliable way to detect a checkout micro-outage is to monitor the flow of conversions rather than technical errors.
A site doing 200 purchases a day does about 8 an hour at peak times. If that number drops to zero for 30 minutes while traffic stays steady, something is wrong.
That's how Korvus's checkout_zero alert works: it continuously monitors the ratio between incoming traffic and purchase events. When purchases stop abruptly while traffic continues, the alert fires within minutes, with an estimate of lost revenue.
The CMO gets a plain message instead of a stack trace: "No purchases detected for 22 min despite 340 active sessions. Estimated loss: €2,800. Checkout probably blocked."
How to limit the impact
Three concrete measures to reduce the cost of checkout micro-outages:
1. Monitor conversions, not just the server
The best indicator of checkout health is the number of purchases per hour compared with baselines, more than server response time. If that ratio drops, something is broken, whatever Datadog says.
2. Automate pausing paid campaigns
When checkout is down, every paid click is budget thrown away. The 15 minutes a human needs to see the alert, understand the problem and pause campaigns cost between €1,500 and €5,000 in useless clicks.
3. Test checkout after every deployment
You don't need a full E2E test, just a simple synthetic one: does the payment form load? Is the "Pay" button clickable? Does the Stripe API respond in under 3 seconds? If those three conditions are met, checkout works.
Key points
- The average cost of e-commerce downtime is €10,000 per minute, and checkout micro-outages are 10 to 50 times more frequent than full outages
- 77% of customers leave for good after a payment error
- An average e-commerce site suffers 2 to 5 checkout micro-outages a month, for a total cost of €7,000 to €17,000
- Backend monitoring doesn't see browser-side failures: only real-time tracking of the conversion flow can detect them
- Every minute of broken checkout while paid campaigns run is a double cost: lost revenue + wasted budget