Uptime Monitoring for E-Commerce: Why Every Minute of Downtime Costs You Money
E-commerce downtime isn't just an inconvenience — it's direct revenue loss, abandoned carts, and customers who don't come back. Here's how to monitor your store so you know about problems before your customers do.
In 2013, Amazon went down for 40 minutes during peak hours. Estimates put the revenue loss at around $5 million. That's $125,000 per minute for one of the world's largest retailers.
You're not Amazon. But the math scales down brutally. If your store does $50,000 per month in revenue, that's roughly $69 per hour. A 2-hour outage during a weekend sale costs you $138 in direct lost sales — plus every customer who tried to buy, couldn't, and didn't come back.
The real cost isn't the immediate lost revenue. It's the compounding effect: abandoned carts don't recover, ad spend that drove traffic to a broken site is wasted, and customers who hit an error page once tend to buy from a competitor next time.
The numbers behind e-commerce downtime
A few data points worth keeping in mind:
| Monthly revenue | Per hour lost | Per minute lost | 2hr outage cost |
|---|---|---|---|
| $10,000/mo | $14 | $0.23 | $28 |
| $50,000/mo | $69 | $1.15 | $139 |
| $100,000/mo | $139 | $2.31 | $278 |
| $500,000/mo | $694 | $11.57 | $1,389 |
| $1,000,000/mo | $1,389 | $23.15 | $2,778 |
Based on average revenue spread evenly across hours. Actual loss during peak hours (evenings, sales events) will be significantly higher.
The table above assumes revenue is distributed evenly across all hours. In reality, e-commerce traffic peaks in the evenings and during promotional periods. An outage during a Black Friday sale or a product launch can cost 5-10x the average hourly rate.
Gartner research estimates the average cost of IT downtime at $5,600 per minute for large enterprises. For SMB e-commerce the absolute number is lower, but the relative impact — as a percentage of revenue and customer lifetime value — is often higher.
What to monitor in an e-commerce stack
A typical e-commerce stack has more failure points than a SaaS application. Each dependency is a potential outage source.
The storefront
The most obvious monitor: your main store URL. If the homepage returns an error, customers can't shop. But check more than the homepage — product pages, category pages, and search all need to work. At minimum:
- Homepage (
GET /) — with content check for a product name or heading that only appears when rendering correctly - A product page (
GET /products/[slug]) — verifies product data is loading - Cart page (
GET /cart) — critical path to purchase
The checkout flow
Checkout is where money changes hands. A broken checkout is the most expensive failure mode — customers have intent to buy and get blocked at the last step. Monitor:
- Checkout page availability
- Payment processor connectivity — many platforms expose a
/healthendpoint that confirms the payment integration is live - Order confirmation endpoint — if orders are being placed but confirmation emails aren't sending, that's a failure worth alerting on
The API and integrations
Modern e-commerce stores depend on external services: inventory management, email marketing, shipping calculators, review platforms. Each is a potential failure point:
- Inventory API: If your inventory system is unreachable, product availability data goes stale. Customers may order out-of-stock items.
- Search: If site search is broken, customers who rely on it to find products will leave.
- Email delivery: Order confirmations, shipping notifications — customers expect these. If your transactional email provider is down, monitor for it.
- CDN / image delivery: A store with broken product images looks broken even if the rest of the site is working.
SSL certificate
An expired SSL certificate is an immediate trust killer. Most browsers show a full-page warning before letting users proceed to a site with an expired cert. For e-commerce, this is catastrophic — no customer will enter payment details on a site their browser is warning them about.
PingBase monitors SSL expiry on all plans and alerts you 30 and 7 days before expiration. This is table stakes for any e-commerce store.
When downtime hurts most: high-traffic periods
Standard uptime monitoring checks every minute. That's sufficient for most situations. But during high-traffic periods — sales, product launches, holiday shopping — consider increasing check frequency and expanding what you monitor.
Before a major sale event:
- Test the checkout flow manually. Automated monitors check that the page loads, but a real test-purchase verifies the entire flow end-to-end.
- Verify payment processor status. Check your payment provider's status page before the event. Stripe, PayPal, and others have their own status pages.
- Set up response time alerts. During high traffic, your site may stay up but slow down significantly. A site that takes 8 seconds to load loses most of its visitors. Configure response time thresholds so you're alerted before it becomes a full outage.
- Prepare your incident communication. Have a status page ready and know who posts updates if something goes wrong. During a sale, you don't want to spend 10 minutes figuring out where to post an incident update.
Response time matters as much as availability
A 2019 Google study found that 53% of mobile users abandon a page that takes more than 3 seconds to load. For e-commerce, Deloitte research found that a 0.1-second improvement in load time increases conversion rates by 8% on mobile.
This means a slow site is almost as bad as a down site. Configure response time alerts alongside availability monitoring:
- Homepage: alert if response time exceeds 2 seconds
- Product pages: alert if response time exceeds 3 seconds
- Checkout: alert if response time exceeds 1.5 seconds — this is the highest-value page, keep it fast
- API endpoints: alert if response time exceeds 500ms
PingBase measures response time on every check and alerts you when it exceeds your configured threshold. The response time graph on each monitor shows you trends so you can catch degradation before it becomes an outage.
The hidden cost: ad spend wasted on downtime
If you're running paid ads — Google Shopping, Meta, TikTok — an outage doesn't pause your campaigns. Your ads keep running, customers click through, hit an error page, and leave. You've paid for the click and got nothing for it.
This is especially painful because:
- Ad platforms optimize for clicks, not conversions. A downtime period can teach the algorithm that your ads don't convert.
- Retargeting pixels fire on page views, not purchases. You may end up retargeting people who visited during a downtime period.
- Customer acquisition cost spikes during outages: same spend, zero conversions.
Fast detection and a paused campaign policy for major outages can meaningfully reduce this waste. The faster your monitoring alerts you, the sooner you can pause spend.
Setting up e-commerce monitoring with PingBase
A complete e-commerce monitoring setup in PingBase takes about 20 minutes. Here's the configuration:
| Monitor | Check | Slow threshold | Content check |
|---|---|---|---|
| Homepage | GET / | 2000ms | product name |
| Product page | GET /products/x | 3000ms | Add to cart |
| Cart | GET /cart | 2000ms | — |
| Checkout | GET /checkout | 1500ms | — |
| API health | GET /api/health | 500ms | "ok" |
| SSL cert | SSL check | — | 30d / 7d alert |
| Order processor | Heartbeat | — | Every 5 min |
Connect all monitors to a public status page. When your store goes down during a sale and customers search "[your store] down," they'll find the status page instead of empty social media. That one change reduces support volume meaningfully.
Monitor your store before the next sale
PingBase monitors your storefront, APIs, and SSL — with a public status page. Free for up to 5 monitors, no credit card.
Get started free →