Uptime monitoring for ecommerce means checking the pages that make money, not just the homepage: a product page, a collection, the cart and the first checkout step, every 1 to 5 minutes, with alerts after two consecutive failures. Add your platform's status feed, your payment provider's status feed and an SSL expiry check, and you cover the failures that cost orders.
This post publishes two weeks before Black Friday 2026 (27 November) and Cyber Monday (30 November). If you run a Shopify or WooCommerce store, use the monitor table and the checklist below to be set up before the first sale email goes out.
What goes wrong in a store that the homepage does not show
Most store owners who monitor anything monitor the homepage. The homepage is usually the most cached, most static page on the site. It is the last page to fail. The pages that break first are the ones that do work on every request:
- Product pages read inventory and pricing. A broken app, a theme update or a database problem shows here first.
- Collection pages run filtered queries and load the most app scripts. Theme and app conflicts surface here.
- The cart exercises session handling and any cart-drawer, upsell or discount app.
- The checkout entry point depends on the payment provider, shipping rates and tax calculation.
- The SSL certificate on a custom domain. When it expires, every page fails with a browser warning while your server is perfectly healthy.
Outage timing matters too. Oh Dear's uptime statistics, drawn from about 1.8 million confirmed outages between March and December 2025, found that 67.7% of outages start outside business hours and that the median outage is resolved in 1.9 minutes. For a store, "outside business hours" is exactly when a sale campaign lands in inboxes across time zones. The outages that hurt are the small share that run for hours because nobody was told.
Shopify: what Shopify monitors and what it does not
Shopify runs the storefront, checkout and admin on its own infrastructure. The Shopify status page lists nine components (Admin, Checkout, Storefront, API and Mobile, Point of Sale and others) and offers a subscribe button for platform incidents. It also carries this note: "Some issues affecting a small percentage of stores may not be reflected here."
That sentence is the whole argument for external monitoring. Shopify's status page tells you about Shopify. It does not tell you about:
- Your custom domain's DNS pointing at the wrong records after a registrar change.
- An expired or mis-issued certificate on a custom domain.
- A theme edit or app install that throws a Liquid error on product pages.
- A password page or "coming soon" page left switched on by mistake.
- A payment gateway whose credentials expired, so checkout loads but cards fail.
On uptime claims: Shopify's Plus platform page states "99.99%" as "Average uptime across Shopify". That is a published average, not a contractual SLA on standard plans. Treat it as a description of the platform, not of your store.
The myshopify.com backup URL
Every Shopify store also answers on its original your-store.myshopify.com address, which does not depend on your custom domain's DNS. Monitor both. If the custom domain is down and the myshopify.com address is up, the problem is DNS or the certificate on your domain. If both are down, it is more likely Shopify, and the status page should confirm it within minutes.
Bot protection and false positives
Shopify's platform security can reject automated requests with an unofficial 430 status code, and its rate limiting answers with 429. Monitoring tools that send a generic user agent from a shared cloud IP range are sometimes caught. If you see 430 or 429 in your check log while the store loads fine in a browser, the monitor is being blocked, not the store. Monitors that let you set a custom user agent or headers can usually work around it. Upmonora cannot set custom headers yet (it is on the roadmap), so if a Shopify storefront returns 430 to its probes, use the consecutive-failure threshold to avoid noise and add the myshopify.com address, which is less often filtered, as a second monitor.
WooCommerce: hosting, caching and plugin failures
WooCommerce is WordPress plus a shop. Everything in the WordPress site down checklist applies, with three store-specific traps.
Caching hides origin failures. A full-page cache or Cloudflare can keep serving the homepage and category pages from cache while PHP or the database is down. The cart, checkout and "My account" pages are never cached, because they are personalised. So a homepage monitor stays green while customers cannot add to cart. Jetpack's Downtime Monitor documentation makes the same point about Cloudflare serving cached copies that mask an outage at the origin. Monitor /cart/ and /checkout/, and if you use Cloudflare, read the Cloudflare 520-524 errors guide to understand what each code says about your origin.
Bot firewalls block monitors. Cloudflare's "Under Attack" mode, Wordfence rate limiting and some hosting firewalls serve a JavaScript challenge or a 403 to anything that is not a browser. A monitor cannot solve a challenge page, so it reports a failure. Jetpack's doc recommends a WAF skip rule for its user agent. Do the same for your monitor's user agent or IP ranges, or expect false alerts whenever the firewall tightens.
Plugin and PHP updates. A plugin auto-update at 03:00 that fatals on checkout is the classic WooCommerce outage. WordPress shows "There has been a critical error on this website" with a 500 status, which a monitor expecting 200-299 catches on the next check. The homepage may still serve from cache, which is one more reason to monitor an uncached page.
The monitor set every store needs
Seven monitors cover a store of any size. The table uses Shopify paths; the WooCommerce equivalents are in the last column.
| Monitor | Shopify URL | WooCommerce URL | Expected | Interval |
|---|---|---|---|---|
| Homepage | https://yourstore.com/ | https://yourstore.com/ | 200 | 1 min |
| Best-selling product | /products/your-handle | /product/your-slug/ | 200 | 1 min |
| Main collection | /collections/all | /shop/ | 200 | 2-5 min |
| Cart | /cart | /cart/ | 200 | 1 min |
| Backup address | https://your-store.myshopify.com/ | Hosting-provided URL or the server IP | 200-399 | 5 min |
| Login or admin | /admin (expect redirect) | /wp-login.php | 200-399 | 5 min |
| SSL expiry | Custom domain | Custom domain | Valid, 14+ days | 12 hours |
Two notes on the table. The Shopify backup address redirects to your custom domain once a primary domain is set, so expect a 301 and let the monitor follow it. On WooCommerce, /wp-login.php is a good proxy for "PHP and the database are up" because it is never cached; expect 200.
Alongside the HTTP monitors, subscribe to two feeds that no HTTP check can replace: your platform's status page (shopifystatus.com, or your host's status page for WooCommerce) and your payment provider's. Stripe publishes RSS and Atom feeds at https://www.stripestatus.com/history.rss and .atom, plus email, SMS and Slack options, documented on its status subscription page. PayPal offers email subscriptions on its production status page at paypal-status.com. When checkout loads but every card fails, the answer is usually on one of those pages.
Intervals, expected status codes and false-positive settings
Three settings decide whether your monitoring is useful or just noisy.
- Interval. One minute for the product page, cart and homepage during peak season. A 5-minute check can miss a 4-minute checkout failure entirely, and during a sale that is real money. Outside peak, 2 to 5 minutes is fine for the secondary monitors. Our interval comparison works through the trade-offs.
- Expected status code. Set it explicitly. A product page should return exactly 200. A Shopify password page returns 200 too, so for the "is the store open" question, monitor a product page and the cart rather than only the homepage. For the admin and backup URLs, accept 200-399 so a redirect counts as up. If a monitor's expected code is wrong, every check is either a false alarm or a false pass; the expected status code post covers the traps.
- Consecutive failures before an incident. Two. One failed check is often a transient network blip or a firewall challenge. Three or more delays the alert by extra intervals. Two consecutive failures at a 1-minute interval means you know within about two minutes of a real outage.
As a concrete example, a cart monitor in Upmonora would be: GET https://yourstore.com/cart, expected status 200-299, 1-minute interval, incident after 2 consecutive failures, follow up to 5 redirects and validate each hop, alert to Slack and email. Recovery closes the incident on the first successful check and records the exact downtime. Maintenance windows keep checks running but silence alerts during a planned theme deploy.
Alerts during a sale: who gets paged
An alert that goes to a shared inbox nobody reads at 23:00 on Black Friday is the same as no alert. Decide this before the sale:
- Primary channel: a Slack or Teams channel with notifications on for the people on duty. The Slack alert setup takes five minutes.
- Secondary channel: email to at least two people, so one person's phone on silent does not block the alert.
- Escalation: if your monitor cannot ring a phone, a webhook can hand the incident to an on-call tool that can. Upmonora sends signed webhooks but not SMS or phone calls, so plan the handoff if you need a wake-up call.
- Ads: agree in advance that whoever gets the alert pauses paid campaigns if the outage passes five minutes. Paying for clicks to a down store is the fastest way to turn a small outage into a large cost. The cost of downtime post has the arithmetic.
Pre-peak-season checklist (Black Friday, Cyber Monday)
Run this list in the week before 27 November 2026, then again before any major campaign.
- Create the seven monitors in the table above. Confirm each one shows "up" for 24 hours before the sale.
- Check the certificate expiry date on your custom domain. If it expires within 30 days of the sale, renew now. Shopify-managed certificates renew automatically; a WooCommerce certificate on your own server depends on your renewal job working. Read how certificate expiry takes sites down if you have not been bitten yet.
- Subscribe to shopifystatus.com or your host's status page, and to your payment provider's feed.
- Freeze theme and plugin changes from the Monday before Black Friday until the Tuesday after Cyber Monday. If you must deploy, use a maintenance window so the monitor does not page the team for a planned restart.
- Send a test alert to every channel and confirm a human sees it on a phone, not just a desktop.
- Whitelist the monitor's user agent or IP ranges in Cloudflare, Wordfence or your hosting firewall, and confirm the checks still pass with the firewall's strictest mode on.
- Write down the two-line runbook: who pauses ads, who posts on the status page, who contacts the host or Shopify support.
- Run a free check of the storefront and checkout pages at upmonora.com/check for anything odd in headers, redirects or TLS that you would rather find now than on 27 November.
Tools for ecommerce uptime monitoring
Any HTTP uptime monitor can run the set above. The differences that matter for a store are the shortest interval, whether you can set the expected status code and redirect behaviour per monitor, and whether the tool can set a custom user agent to get past bot protection. For stores that need a scripted test order (add to cart, apply discount, reach the payment step), look at transaction or synthetic monitoring, which is a separate product category from uptime checks. The best uptime monitoring tools roundup compares the usual options with their real limits.
Upmonora covers the HTTP and SSL half of the list: checks from every 30 seconds on the Business plan, expected status ranges, five-hop redirect validation, two-failure incident thresholds and Slack, Teams, email and webhook alerts. It does not do transaction monitoring, and it cannot monitor pages behind a login yet. The Free plan's 5 monitors at a 5-minute interval cover a small store outside peak season; the 1-minute interval starts at the Starter plan on the pricing page. Start free, no card needed, and have the store monitored before the first sale email goes out.
Frequently asked questions
Will Shopify notify me when my store is down?
Shopify only notifies you about platform-wide incidents, and only if you subscribe to updates on shopifystatus.com. It does not watch your individual store, so a broken domain, an expired certificate on a custom domain or an app that breaks your theme will not trigger any message from Shopify. External uptime monitoring is the only way to get a store-specific alert.
Does Shopify guarantee uptime?
Shopify advertises 99.99% average uptime across the platform on its Shopify Plus page, but that is a published average, not a contractual guarantee for standard plans. Even at 99.99%, the figure describes Shopify's infrastructure, not your domain, DNS, theme or apps, which is where most store-specific outages begin.
How do I monitor my WooCommerce store for downtime?
Monitor your WooCommerce store from outside with an HTTP uptime monitor that requests the homepage, a product page, the cart page and wp-login.php every 1 to 5 minutes and alerts after two consecutive failures. Add an SSL expiry monitor and, if you use Cloudflare, make sure the monitor can reach the origin rather than a cached copy.
Can I monitor my checkout page?
A plain HTTP monitor can check that the cart page and the start of checkout return the expected status code, which catches most full outages. It cannot complete a purchase, so a payment gateway that rejects cards or a shipping calculator that fails will not show up. For that you need transaction (synthetic) monitoring that scripts a real test order.