To monitor an online store for downtime, check it from outside your network every 30 to 60 seconds, assert that key pages contain the words and prices that prove they actually rendered (not just a 200), watch the cart, checkout and SSL separately, and send alerts by SMS so a night outage actually wakes someone. That is the whole discipline. The trap most store owners fall into is trusting the status code, and the status code is the one signal a broken store is happy to keep sending you.
Why a 200 is not "up" for a store
A status code of 200 means the server received the request and returned a response. It says nothing about what was in that response. Your store can return 200 on a page that is blank, on a page showing a database error inside a nicely styled template, on a "this store is unavailable" holding page, or on a homepage whose product grid failed to load because an app timed out. The server did its job. The buyer sees nothing they can purchase.
This is the false-green problem, and it is worse for stores than for almost any other kind of site. A store that half-renders loses you every sale for as long as it lasts, and status-code monitoring shows a calm, unbroken line of green the entire time. You find out from a customer email, which is the most expensive way to learn your store was down. It is worth being blunt with yourself and knowing what a stalled storefront actually costs in lost income, because that number is what justifies watching more than the status code.
the false green
A store can serve a perfect 200 while showing a maintenance page, an empty product grid, a stack trace, or a payment form that will not submit. Status-code monitoring reports all four as healthy. The fix is to check what the page actually said, not just that it answered.
The pages that actually need watching
You do not monitor "the store." You monitor the specific pages that stand between a visitor and their money, because those are the ones whose failure costs you. There are five.
| What to check | Why it matters | How to assert it |
|---|---|---|
| Homepage | First impression and the entry to everything else | Assert the page contains your brand name or a known headline, not just a 200 |
| A top product page | Where intent turns into a decision | Assert the product title and the price string are both present |
| Cart | The step where "want" becomes "buy" | Assert the cart page loads and shows its expected labels |
| Checkout reachability | No checkout, no revenue, full stop | Assert the checkout URL returns and renders its form markup |
| Search | How many buyers find what they came for | Assert a known query returns results, not an empty state |
You do not need a synthetic bot that clicks through a full purchase to get most of this value. Watching each of these pages as its own monitor, with a content assertion on each, catches the overwhelming majority of real store failures: a theme update that blanks the product grid, an app that breaks the cart, a checkout that starts throwing errors. The deeper checkout walkthrough in how to monitor WooCommerce uptime and checkout applies to any platform.
Content assertions vs status codes
A content assertion is a rule that says "this response is only healthy if it contains this text." Instead of accepting any 200, you tell the monitor to look for the product title, the price, an "Add to cart" label, or your store name in the page body. If the words are missing, the check fails and you get alerted, even though the server returned 200.
Pick a string that is only present when the page rendered correctly. A price like
$49.00 is a good choice for a product page, because a price only appears when the
product data loaded; logo alt text or a footer line works for the homepage. For anything that
speaks JSON, such as a headless storefront or an inventory endpoint, you can
assert on JSON fields
directly, so an empty items array or a missing price field fails the check even when
the API answers cleanly. AlertPing supports keyword and body assertions and JSON-path assertions,
which is what makes this practical rather than theoretical.
SSL and the custom domain
Two of the most common ways a store goes dark have nothing to do with your code. The first is an expired TLS certificate. When it lapses, browsers throw a full-screen security warning and most shoppers leave, but your server keeps returning 200, so status-code monitoring stays green through the whole thing. Watch the certificate separately with SSL certificate monitoring so you are warned weeks before expiry, not by a customer screenshot.
The second is the custom domain itself. Domains expire, DNS records get edited, and a nameserver change can point your store at nothing while the platform underneath is fine. Monitoring the live domain your customers actually use, rather than an internal or platform URL, is the only way to catch this class of failure.
Multi-region, interval, and SMS
Where you check from matters. A store can be reachable from one part of the country and unreachable from another because of a CDN edge problem or a regional network issue. A single location can miss that, or fire a false alarm because that one probe had a bad minute. Checking from multiple regions and confirming a failure across more than one before paging you gives both fewer false alarms and real coverage. AlertPing runs checks from two regions (US East and EU Central) and confirms every failure from the second one.
Interval is the second lever. A store checked every 15 minutes can be down for 14 minutes before the monitor even looks, which on a busy storefront is a meaningful pile of lost orders. A 30 to 60 second interval means you learn about an outage while it is minutes old, usually before your customers have started emailing.
None of it matters if the alert arrives somewhere nobody is looking. Outages do not respect business hours, and an email sitting unread at 2am is a record, not an alert. Send a text message so a night outage actually wakes someone, and route it to whoever can act. Flat plans from $49 a month include SMS, so paging a human is not a metered surprise on your bill.
Hosted vs self-hosted and who is responsible for what
Where your store lives changes what you can fix, but not what you should watch. The instinct on a hosted platform is "the platform handles uptime, so I do not need to," and that is wrong in a costly way.
On Shopify uptime monitoring and similar hosted platforms, you genuinely cannot fix a platform-wide outage, and those are rare. But the platform's published uptime number excludes almost everything that actually takes your store down: a theme edit that breaks the product page, an app that fails and blanks the cart, an expired certificate, a DNS change, an unpaid platform bill that flips your store to a holding page. Every one of those is your responsibility, none of them dents the platform's uptime figure, and all of them return a 200. Monitoring is how you catch the failures that number was never counting. If you are staring at a broken storefront right now, the walkthrough of why a Shopify store shows as unavailable works through those causes one at a time.
On self-hosted platforms like WooCommerce or Magento, you own the entire stack: the server, PHP, the database, the plugins, the certificate, the CDN. There is more to break and it is all yours, so the case for watching every money-taking path from the outside is even stronger. Either way, external monitoring turns "the store is down" from a customer discovery into your own, earlier one, which is exactly what ecommerce website monitoring is built to do.
A setup checklist
If you do nothing else, do these, roughly in order of payoff:
- Homepage monitor asserting your store name or a known headline, every 30 to 60 seconds.
- Top product page monitor asserting the product title and price are both present.
- Cart and checkout monitors asserting each renders its expected form and labels.
- SSL certificate monitor on the custom domain, warning weeks ahead of expiry.
- Multi-region checks so a regional or CDN edge problem is caught and confirmed.
- SMS alerts routed to a person who can act, tested once so you know it fires.
- A public status page so you are not answering the same "are you down" email twenty times.
Then break one on purpose. Point a monitor at a page that does not exist, or tighten an assertion so it fails, and confirm the SMS actually lands. An untested alert is a hope, not a safety net.
How do I know if my online store is down?
Check it continuously from outside your own network and assert on page content, not just the status code. A monitor that loads your homepage, product page and checkout every 30 to 60 seconds and confirms the expected text rendered will page you the moment a buyer would hit a broken page, usually before any customer notices.
Can a website show 200 and still be broken?
Yes, and for stores it is the common case. A 200 only means the server answered. It can answer with a blank page, a maintenance holding page, a styled error, an empty product grid, or a checkout that will not submit. The only way to catch these is to assert that the response contains the words or prices that prove the page actually worked.
How often should I check my store?
Every 30 to 60 seconds for the pages that take money. Longer intervals mean an outage can run for many minutes before the monitor even looks, and on a busy storefront each of those minutes is lost orders. A short interval from multiple regions catches problems while they are fresh and filters out one-off network blips before they page you.
Does uptime monitoring cover checkout?
Only if you point it at checkout specifically. Monitoring the homepage tells you nothing about whether the cart or payment form works. Add a monitor on the cart and the checkout URL, assert that each renders its expected form and labels, and you will know when the single most important page on the store breaks, instead of guessing from a drop in sales.
The short version
A store can return a flawless 200 while it is completely unable to sell, so a status code alone is false comfort. Monitor the paths that take money: homepage, a top product page, cart, and checkout reachability. Assert on the page content, not just the response, so a blank grid or a dead form fails the check. Watch SSL and the custom domain separately, check from multiple regions every 30 to 60 seconds, and alert by SMS so an outage at 2am reaches a person. On a hosted platform you can still catch the theme, app, DNS and SSL failures its uptime number ignores. On self-hosted you own all of it. Either way, the goal is the same: find out before your customers do.