An ecommerce site has a stricter definition of "down" than most web apps. A marketing page that returns a 500 for two minutes is an inconvenience; a checkout that returns a 500 for two minutes is revenue you will never recover. Shoppers who hit a broken cart don't come back later — they open a competitor's tab in the same window. The cost of ecommerce downtime isn't just lost minutes, it's lost customers, and it compounds during the peaks (Black Friday, product drops, holiday sales) when most of your annual revenue can land in a single afternoon.
This guide covers what to monitor on an ecommerce site, with a focus on the parts that directly gate revenue: the storefront, the cart and checkout flow, and the payment gateway. It's platform-agnostic — the same principles apply whether you run Shopify, Magento, Bigcommerce, WooCommerce, or a custom build — and it complements our platform-specific guides for Shopify monitoring and Magento monitoring.
What counts as ecommerce downtime
Not every page on an ecommerce site is equally load-bearing. The blast radius of a failure depends on where it happens:
| Layer | Example failure | Revenue impact |
|---|---|---|
| Storefront / homepage | 500 on /, slow LCP |
Brand damage, reduced sessions |
| Product detail page (PDP) | 404 on a top seller, missing variants | Lost sales on that product |
| Search / category | Empty results, broken facets | Sessions leave without converting |
| Cart | Cart won't add, cart empties on refresh | Conversion killed mid-funnel |
| Checkout | 500 on /checkout, address validation down |
Hard revenue loss, abandoned cart |
| Payment | Stripe/PayPal/Adyen 5xx, 3DS timeout | Hard revenue loss + failed trust |
| Inventory / order sync | Stock count wrong, orders not written to ERP | Oversells, fulfillment failures |
A homepage being down is bad. A checkout or payment endpoint being down is an incident, full stop. Your monitoring has to weight those layers differently — a 30-second blip on /checkout should page someone immediately, while a 30-second blip on /about probably shouldn't. Quantify the exposure first with a website downtime cost calculator so the team agrees on what "revenue-critical" actually means for your store.
What to monitor on an ecommerce site
A bare GET / returning 200 tells you almost nothing about whether shoppers can actually buy. A real ecommerce monitoring setup checks every layer of the purchase funnel:
Storefront & PDPs
Synthetic checks against the homepage and your top-trafficked PDPs. Don't just assert 200 — assert that the page contains the elements that make it a product page (price, add-to-cart button, stock indicator). A PDP that renders without a price because the pricing service timed out is functionally broken even if it returns 200. Use content change detection to flag when a top PDP silently drops a key element.
Cart & checkout flow
A multi-step monitor that adds an item to the cart, proceeds through checkout, and reaches the payment step. Each step is an assertion: cart count increments, the checkout form loads, shipping quotes return, tax calculates. This is the single most valuable monitor on an ecommerce site because it walks the exact path revenue travels. A broken checkout that returns 200 on GET /checkout but 500s on POST /shipping will be invisible to a homepage-only monitor.
Payment gateways
Direct monitoring of your payment providers' API endpoints (Stripe, PayPal, Adyen, Braintree) with authenticated requests. A payment gateway returning 5xx is the most expensive failure mode on your site — see 5xx server errors explained for what those codes mean at the gateway. Because payment APIs require auth, monitor them with bearer tokens and custom headers so the check exercises the real path, not a public endpoint.
Search & merchandising
If your search is powered by Algolia, Elasticsearch, or a Shopify Search API, monitor it directly. A search box that returns zero results for every query is a conversion killer that homepage monitors miss entirely. Run a probe with a known-good query and assert the expected product appears.
Inventory sync
If you sync inventory from an ERP, PIM, or warehouse system, monitor the sync job's heartbeat with heartbeat / cron monitoring. A stalled sync means oversells (selling stock you don't have) or undersells (showing "out of stock" on products you do have) — both expensive in different ways.
Third-party scripts
Analytics, tag manager, chat widget, review widget, ad pixels. These don't break checkout directly, but a bloated or failing third-party script can drag Core Web Vitals below Google's thresholds and hurt both SEO and conversion rate.
Payment gateway monitoring
Payment is the layer where monitoring discipline pays for itself. Treat each payment provider as a first-class dependency with its own monitor:
- Probe the API directly. Send an authenticated request to the provider's status or tokenization endpoint (the one that doesn't create a charge) and assert the response. Stripe's
/v1/tokensand Adyen's/pingare good candidates. This catches provider outages before your customers hit them. - Watch 5xx and 429 from your integration. Your own backend logs every call to the payment provider. Alert on rising 5xx (provider failing) and 429 (you're being rate-limited) — see API rate limit monitoring and 429 alerting for handling the 429 case.
- Latency, not just status. A payment API returning 200 in 12 seconds is just as fatal as one returning 500. Set response-time alerts at the p95 your checkout can tolerate — usually 2–3 seconds before the shopper abandons.
- 3DS and webhook callbacks. If you use 3D Secure or provider webhooks for async payment confirmation, monitor the webhook receiver itself (see incoming webhook endpoint monitoring) and the 3DS redirect round-trip.
When a payment provider goes down, your options are limited to graceful degradation (offer a second provider, mark affected payment methods as temporarily unavailable) — but only if you know it's down. Direct monitoring is how you know.
Checkout-specific failure modes
Checkout fails in characteristic ways that generic monitoring misses:
- Session and cookie loss. A checkout that loses the session between cart and payment drops the order entirely. A multi-step monitor that carries cookies across requests catches this; a stateless
GET /checkoutdoes not. - Rate limiting on the shopper's path. Some CDNs and WAFs rate-limit by IP; a shared office or a bot-protected checkout can start returning 429 to legitimate shoppers. Distinguish this from API rate limits — see consuming rate-limited APIs.
- CDN and edge failures. A checkout served from a cached edge can return stale or partial HTML when the origin is degraded. Monitor from multiple regions with multi-region monitoring so a single-region CDN issue doesn't look like a global outage.
- Coupon and promo code endpoints. A broken promo service means every shopper with a code sees "invalid code" and abandons. Probe a known-good code on a test cart.
- Tax and shipping quote services. Third-party tax (TaxJar, Avalara) or shipping (EasyPost, ShipEngine) APIs timing out blocks checkout progression. Monitor them like payment — they're on the critical path.
Peak traffic: Black Friday & launches
The failures that hide all year surface during peak traffic. A checkout that handles 50 RPS fine can fall over at 500 RPS because of a cache stampede, a database connection pool that finally saturates, or a third-party API that starts rate-limiting you. Read our peak traffic monitoring guide for the full playbook, but the monitoring essentials for a peak event:
- Lower your alert thresholds the week before. A 1% 5xx rate that's tolerable in October is an incident on Black Friday.
- Add peak-specific monitors. Synthetic checks that hit the exact promo landing pages and the featured products, not just the homepage.
- Pre-warm and load test. Load testing before the event tells you where the ceiling is; monitoring during the event tells you when you're approaching it.
- Status page ready. Have a status page staged so that if peak does break something, shopper-facing communication is one click away.
How Webalert Helps
Webalert is built for the layered monitoring an ecommerce site needs:
- Multi-step API monitors with assertions walk the cart → checkout → payment path and verify each step returns what it should, not just a 200. This is the single highest-value monitor for an ecommerce store.
- Authenticated API monitoring lets you probe Stripe, PayPal, Adyen, and your own internal APIs with bearer tokens and custom headers — see monitoring authenticated APIs.
- Response-time alerts at p95 catch the slow-but-200 failures that kill checkout conversion before they hit your revenue numbers.
- Content and DOM change detection flags when a top PDP silently drops its price, add-to-cart button, or stock indicator — the kind of failure that returns 200 but sells nothing.
- Multi-region checks so a CDN or regional edge failure doesn't masquerade as a global outage (or vice versa).
- Public status page with a custom domain keeps shoppers informed during incidents and protects trust — see how to build a status page.
- Heartbeat monitoring for inventory sync jobs and order-export cron tasks so a stalled ERP integration can't quietly cause oversells.
Webalert won't fix your checkout, but it will tell you the moment your checkout stops accepting orders — and confirm the moment it's accepting them again.
Summary
Ecommerce downtime is a revenue problem, not just a reliability problem, and "down" means more than "homepage returns 500". The blast radius of a failure depends on the layer: a broken homepage is bad, a broken checkout or payment gateway is an incident. A real ecommerce monitoring setup walks the purchase funnel with multi-step assertions, monitors payment providers directly with authenticated requests, watches checkout-specific failure modes (session loss, CDN edge failures, rate limits on the shopper path), and treats peak events with lowered thresholds and pre-warmed monitors. Pair synthetic outside-in checks with internal dependency monitoring so a revenue-layer failure reaches you in seconds, not after the sales report comes in tomorrow.
Ecommerce monitoring checklist
- Multi-step monitor walks add-to-cart → checkout → payment, with assertions at each step
- Top 5–10 PDPs monitored with content/DOM assertions (price, add-to-cart button present)
- Payment gateway APIs (Stripe/PayPal/Adyen) monitored with authenticated requests
- Search monitored with a known-good query and expected product assertion
- Response-time alerts set at p95 thresholds for checkout and payment (≤2–3s)
- Inventory / ERP sync jobs covered by heartbeat monitoring
- Checkout monitored from multiple regions
- Promo/coupon, tax, and shipping quote endpoints probed
- Public status page staged and ready for peak events
- Alert thresholds lowered the week before a peak (Black Friday, launch)
Frequently Asked Questions
What should I monitor on an ecommerce website?
Monitor every layer of the purchase funnel: storefront and top product pages with content assertions, the cart and checkout flow as a multi-step monitor, payment gateway APIs with authenticated requests, search with a known-good query, inventory sync via heartbeat monitoring, and response time at p95 for checkout and payment. A homepage-only GET / returning 200 is not ecommerce monitoring.
How do I monitor a payment gateway like Stripe?
Send an authenticated request to a non-charging endpoint (for example Stripe's tokenization or a provider's /ping or status endpoint) and assert the response. Also alert on rising 5xx and 429 from your own integration's calls to the provider, and on latency at the p95 your checkout can tolerate. Treat the payment provider as a first-class dependency with its own monitor.
What is the most important monitor for an ecommerce site?
A multi-step monitor that adds an item to the cart, proceeds through checkout, and reaches the payment step, with assertions at each step. It walks the exact path revenue travels and catches failures (broken shipping quotes, session loss, 3DS timeouts) that a homepage monitor will never see.
How is ecommerce monitoring different from regular website monitoring?
The definition of "down" is stricter and revenue-weighted. A 30-second blip on /about is tolerable; the same blip on /checkout is an incident. Ecommerce monitoring requires multi-step funnel checks, authenticated payment API probes, content assertions on product pages, and peak-event readiness — generic uptime monitoring doesn't cover any of that.