Uptime Monitoring for Ecommerce Stores: SMB Playbook

Uptime is not the same as availability

Uptime is whether the URL responds. Availability is whether a customer can complete the purchase. Those are different events, and a tool that only watches the first one will miss the second one routinely.

Imagine the homepage returns a 200 OK, the product pages render, and the Add-to-Cart button posts to a checkout endpoint that has been silently 500'ing for two hours because a third-party tax-calculation API rotated its key. Storefront uptime: 100%. Checkout availability: 0%. A pure HTTP monitor on the homepage will tell you everything is fine.

The three failure surfaces

For a small ecommerce store, three things can fail independently and each one needs its own check:

1. Storefront — the homepage and product pages render
2. Checkout — adding to cart, entering shipping, submitting payment all work end-to-end
3. Certificate — the TLS cert hasn't expired and isn't about to

The rest of this piece is structured around those three layers. We don't cover infrastructure metrics (CPU, memory, disk) — that's server monitoring, a separate category.

The minute-level revenue formula

loss per minute = monthly revenue ÷ (open hours per month × 60)

A worked example

A €40,000/month Shopify store, open 10 hours per day, 30 days per month:

open hours per month = 10 × 30 = 300
loss per minute = 40000 ÷ (300 × 60) = €2.22 per minute

A 30-minute checkout outage at midday on a peak-traffic day costs about €67 in direct revenue. A 6-hour outage costs about €800.

What the formula leaves out

The formula above is direct revenue lost while the site is down. It doesn't include:

• Abandoned-cart re-marketing waste. Email and ad traffic you've already paid for lands on a broken page.
• Refund and chargeback exposure. If payment was taken but the order didn't complete, you have a customer-service problem before you have an accounting problem.
• Customer-service load. Every minute of visible downtime turns into "is your site down?" tickets for the next 24 hours.

We deliberately don't quote a number for the SEO impact of repeated downtime. We couldn't find a primary source that quantifies it cleanly enough to repeat, so we're leaving that one alone.

A reference incident page worth bookmarking

If you want a calibrated sense of what platform-level outages look like in public, the Shopify status page logs incidents across Admin, Checkout, Reports and Dashboards, Storefront, API & Mobile, Third party services, Support, Point of Sale, and Oxygen [src-1]. It's the answer to "is it Shopify, or is it me?" when something breaks at 02:00.

Layer 1 — Storefront uptime

A 60-second HTTP check from at least two regions, with a keyword assertion on the page body so a blank 200 doesn't pass.

GET https://yourstore.com/
Expect: status 200
Expect: body contains "Add to cart"
Interval: 60 seconds
Regions: 2 minimum, multi-region confirmation before alerting

Without the keyword assertion, a CDN-cached error page or a placeholder maintenance screen will return 200 and the monitor will sleep through the outage.

Layer 2 — Checkout flow

A synthetic transaction at a 5- to 10-minute interval. This is the layer the SERP barely covers — most "ecommerce monitoring" articles say "use transaction monitoring" and stop there. The setup walkthrough is in §5.

Why not 60 seconds like layer 1? Because synthetic checkout runs hit your real cart, real session storage, sometimes real payment gateways in test mode. Running a synthetic checkout every minute creates load and noise; every 5–10 minutes is enough to catch a sustained outage without polluting your data.

Layer 3 — SSL / domain expiry

A daily check is enough. The alert lead time is the part people get wrong:

• Cert expiry alert: 14 days minimum lead time. Long enough to renew during a normal week, not the morning of.
• Domain expiry alert: 30 days minimum lead time. Domain renewals can fail silently if a saved card expires; you want runway to notice.

A note on real-user monitoring (RUM)

RUM watches what real customers experience as they browse — page-load times in their actual browser, errors they hit, how the site behaves on a 4G connection in Lisbon. Synthetic monitoring (what this piece is about) watches what a scripted probe sees from a known location.

The two are complementary, not substitutes. Synthetic catches outages and regressions before real customers do; RUM catches problems that only show up at scale or on devices your synthetic probes don't represent. RUM is a separate tool category; we don't cover it here.

What the check does

1. Load the product page for a known product
2. Click "Add to cart"
3. Assert the cart count incremented (DOM change)
4. Assert no JS console errors during the run
5. Leave the cart — do not proceed to payment, do not commit a real order

That last point is the one people get wrong, and the rest of this section is mostly about not getting it wrong.

Step 1 — pick a low-stock-safe SKU

The SKU you check against should be:

• In stock and not at risk of selling out (a 5-minute monitor on a sold-out SKU pages you for a real condition the customer would also see, but it's not what you're trying to test)
• Cheap enough that price changes don't break your dashboards if you sample order values from monitoring data
• Not part of an A/B test or conditional offer (variant selection adds steps that drift)

If you don't have a candidate SKU, create a hidden product specifically for monitoring. On Shopify and WooCommerce both, an unlisted product that's only reachable by direct URL is straightforward.

Step 2 — record the click path

Two reasonable options:

• Use Chrome DevTools Recorder to capture the click sequence on your real site, then export to JSON or to your monitoring tool's format. Google's own tutorial for the Recorder panel walks through a coffee-shop checkout flow — add to cart, go to cart, remove an item, start checkout, fill payment, check out — which generalises directly [src-2].
• Use your monitor's own recorder if it has one. Most synthetic-transaction tools do.

Either way, run the recording end-to-end at least three times against your real store before scheduling it. Synthetic recordings are fragile to selectors that change between sessions (auto-generated CSS classes, locale-aware text), and you want to catch the fragility on minute one, not at 03:00.

Step 3 — define your assertions

A good synthetic check fails for the right reason. Bad assertions:

• "Page contains the word 'Cart'." Too broad; passes when the cart is empty too.
• "DOM has the element .cart-count." Passes when the element exists with value 0.

Better assertions:

• The numeric value inside the cart-count element incremented by 1
• The cart subtotal is greater than 0
• The console produced zero errors during the run
• The final URL is the cart or product page (not a 404 or login redirect)

Step 4 — schedule and route alerts

• Interval: 5 minutes is a reasonable default for most stores. Drop to 10 minutes if your monitoring spend is tight.
• Multi-region confirmation: require the failure to reproduce from at least two regions before paging anyone. This is the single biggest false-positive reducer there is.
• Routing: for an SMB store, email + one secondary channel (Slack or SMS) is usually enough. You don't need a PagerDuty rotation for this.

Step 5 — handle false positives

Three common causes:

• Bot-protection challenges. Cloudflare, DataDome, or similar mistaking your monitor for a bot. Solution: allowlist your monitor's IPs at your WAF, or use a known-user-agent header your WAF lets through.
• A/B-test variants. A new variant changes the DOM and the selector breaks. Solution: pin the test SKU's page out of the experiment.
• Sold-out states. The SKU sold out and the Add-to-Cart button rendered as "Notify me." Solution: rotate to a different SKU, or use a hidden monitoring-only product.

Common mistakes

• Running the check with a real customer account that accumulates carts and orders. Use a dedicated monitoring account.
• Leaving items in carts that count toward inventory holds. Make sure the synthetic flow ends by clearing the cart or letting the session expire.
• Paging on a single-region failure. See multi-region confirmation, above.

The table

EU data residency, multilingual interfaces, and multi-region confirmation aren't in the table because most vendors don't surface them on their pricing pages — we cover those in §7 and §9 narratively, citing each vendor's own published material where it exists.

Tool blurbs

Pingdom. The incumbent. Brand recognition with US-side procurement and the integrations to back it. Pricing is now split into Synthetic and RUM as separately-quantified products: Synthetic Monitoring starts at €14.33/mo (annual) for 10 Uptime checks + 1 Advanced check + 50 SMS alerts; the smallest combined Synthetic + RUM subscription is €343.92/yr [src-3]. Where it loses for an SMB store: per-product packaging punishes anyone who needs both Synthetic and RUM at small scale.

Better Stack (Better Uptime). Modern UI, status pages people generally like, on-call rotation built in. Pricing is per responder license — $29/mo annual or $34/mo monthly per responder, with a free tier covering 10 monitors and 1 status page [src-4]. Status pages: 1 included; additional public status pages cost $12/mo annual each, white-labelling costs $208/mo annual per page [src-4]. The per-license model is what makes this expensive at agency scale (more on that in §8).

UptimeRobot. The popular free-tier choice. Free plan covers 50 monitors at 5-minute intervals — generous, but 5 minutes is too slow for ecommerce checkout monitoring [src-5]. Solo plan starts at $7/mo annual ($8/mo monthly) at the low end of the slider, dropping to 60-second intervals on 10 monitors; the slider's upper end is $9/mo annual for a higher monitor count [src-5]. API monitoring, multi-location, slow-response alerts and DNS monitoring are flagged on Solo and above; full status pages start on Team ($29/mo annual at the low slider end) [src-5].

Site24x7. Part of Zoho. Broad feature set, including a dedicated Synthetic Web Transaction Monitoring product line, a Site24x7.eu data centre option in the footer region selector, and 18 dashboard languages [src-6]. Pricing was not verifiable in this draft pass — the canonical pricing URL /plans-and-pricing.html returned 404 on 2026-05-05, and we won't quote a tier we can't confirm against the live page.

Checkly. The developer's choice. Synthetic monitoring built on Playwright, native API checks, monitoring-as-code via CLI and Terraform. Hobby tier free (10 monitors at 2-min); Starter at $24/mo annual for 50 monitors at 1-min; Team at $64/mo annual for 75 monitors at 30-sec intervals across 22 locations [src-7]. Where it loses for the typical SMB store owner: it's pitched at engineering teams, not store owners — the dashboard assumes Playwright fluency.

StatusCake. UK-based, mid-market, decent for small businesses. Free tier covers 10 uptime monitors at 5-minute intervals (plus 1 page-speed, 1 domain, 1 SSL monitor) [src-8]. Superior at €16.66/mo annual covers 100 uptime monitors at 1-min for 2 team members; Business at €58.33/mo annual covers 300 uptime monitors and 30-second intervals for 9 team members [src-8]. Synthetic-transaction support is not surfaced on the pricing tier comparison.

Uptimia. Listed honestly and not at #1 of our own list. Per-monitored-site pricing with no per-seat tax. Basic plan $9/mo monthly (annual discount up to 2 months free) covers 10 Uptime checks + 1 Advanced check + 1 SSL website; Professional $39/mo for 100 Uptime + 10 Advanced + 10 SSL websites; Enterprise $199/mo for 1000 Uptime + 100 Advanced + 100 SSL websites [src-10]. Transaction monitoring is included on all plans and described on the pricing page as "Extended monitoring for your website applications, such as login, sign up and checkout forms" [src-10]. Public Status Page and a multilingual interface (English, Deutsch, Français, Português, Español, Italiano, Nederlands) are listed on the homepage; checks run from 171 monitoring locations with 83 in Europe [src-11]. Where we lose: status-page polish vs. Better Stack (theirs is more refined) and brand recognition vs. Pingdom (we have less of it). If status pages are the centre of your pitch to customers, look at Better Stack first; if you're already in the SolarWinds procurement queue, Pingdom is easier than introducing us.

What is a good uptime percentage for an ecommerce website?

99.9% ("three nines") allows about 8.77 hours of unplanned downtime per year (math: 0.001 × 8,760 hours). 99.95% allows about 4.4 hours/year, and is achievable on a well-architected setup but typically requires redundancy at the platform layer, not just monitoring. 99.99% ("four nines") — about 53 minutes/year — usually requires active-active hosting and is rarely necessary at SMB scale.

How is uptime monitoring different from APM or RUM?

Uptime monitoring asks "is it up?" from the outside, on a schedule. APM (application performance monitoring) instruments your code to tell you why a request was slow or threw an error. RUM (real-user monitoring) watches what real customers experience in their actual browsers. The three are complementary: uptime monitoring catches outages first, APM diagnoses them, RUM tells you whether your real customers experienced them.

Is free uptime monitoring enough for a small store?

For a homepage 200-OK check, often yes — UptimeRobot's free tier (50 monitors at 5-minute intervals) [src-5] and StatusCake's free tier (10 uptime monitors at 5-minute intervals) [src-8] both cover the basics. What you don't get on either free tier is synthetic checkout monitoring, which is the layer that loses you actual revenue when it fails. If your monthly revenue is high enough that a 30-minute checkout outage costs more than €20–30, paying for a tier with synthetic transactions is the cheaper option.

Does Shopify already monitor my store?

Shopify monitors the Shopify platform — its admin, checkout, storefront, API and other layers. The public status page at shopifystatus.com logs platform-level incidents [src-1]. What Shopify does not monitor: your individual store's custom theme code, third-party app failures specific to your store, your own DNS or domain, or your store-specific checkout flows. Those are yours to monitor.

How do I monitor add-to-cart specifically?

Synthetic transaction monitoring — a scripted browser session that loads a product page, clicks Add to cart, and asserts the cart count incremented. The full setup walkthrough is in §5 of this piece.

What's the difference between uptime and availability for ecommerce?

Uptime is whether the URL responds. Availability is whether a customer can complete the purchase. A site can be at 100% uptime and 0% availability simultaneously — the homepage returns 200 while the checkout endpoint silently 500s. Monitoring only the first one is the most common gap on small-store setups.