ecommerce store monitoring
Ecommerce website monitoring for your storefront, cart, checkout and SSL
Short answer: an online store can return a perfect HTTP 200 while it is unbuyable, so status-code-only monitoring reports green while you sell nothing. The failures that actually cost sales are quieter: a broken theme, an app that jams the cart, a payment script that stopped loading, an expired certificate, a checkout that times out under load. AlertPing checks your real store URLs every 30 seconds from three regions and reads the page content, not just the status code, so the alert fires when a customer could not buy, not only when the server stopped answering.
Last updated July 2026 · 30-second checks on every plan
alertping ▸ run check
live
▸ type a domain and run a real-feel check
▸ probes from 3 regions · FRA · IAD · SIN
▸ waiting…▌
queued probing▌
If ever goes down, you get:
Alert fired ▸ 2 channels · 6.2 s after first failure
AlertPing app
● DOWN : HTTP timeout confirmed from 3/3 regions (FRA, IAD, SIN). Incident opened.
sms · on-call
AlertPing: DOWN. Confirmed 3/3 regions . First fail: Frankfurt.
start here
A store can return 200 and still take zero orders
This is the failure mode that catches ecommerce teams out, and it is why watching a store as one URL with a status-code check gives false comfort. The web server can answer perfectly while the part that moves money is broken.
The add-to-cart button is dead
A theme edit or an app update breaks the button's script. The product page loads, looks fine, and returns 200. Nobody can add anything to a cart. A status-code monitor sees a healthy store.
Checkout times out under load
A flash sale sends traffic the payment step cannot handle. The homepage still serves from cache, so uptime looks green, while the checkout that actually needs a database quietly fails for real buyers.
The payment script stopped loading
A third-party gateway or tag manager script fails to load. The page renders, the button is there, and clicking it does nothing. The HTTP response says everything is fine.
The fix: check for words, not just codes
Point each check at a real store URL and assert that the response body contains a string that only appears when the page genuinely works: a price, the "Add to cart" label, an "Order summary" heading on the cart. Then invert one, alerting if the body contains an error page's text. This is the same idea as asserting on JSON fields in an API response, applied to a rendered store page, so the monitor fails when the page stops saying the thing it should, not only when the server stops answering. The full walkthrough is in how to monitor an online store for downtime.
the paths that take money
What to monitor on an ecommerce site, and how
The useful question is not "is the site up?" It is "can a customer find a product, add it, and pay?" Those steps fail independently, so watch each one on its own with a content assertion, not just the domain.
| What to check | Why it matters | How to assert it |
|---|---|---|
| Homepage | The front door and your most-cached page, so it hides deeper failures | Assert a phrase that only renders when the theme works, not just a 200 |
| Top product page | The page that has to work for money to move at all | Assert the price and the add-to-cart text both appear |
| Cart | Apps inject scripts here more than anywhere, so it breaks alone | Assert the cart or order-summary text renders |
| Checkout reachability | Where load and payment scripts fail while the rest looks fine | Check the checkout URL responds and shows the expected step |
| Search or category | A dead search or empty category quietly kills conversion | Assert results markup appears for a known query |
| SSL certificate | An expired cert throws a browser warning at every visitor | Watch expiry ahead of time, not after the padlock breaks |
| The www redirect | A redirect loop after a migration is silent and expensive | Check www lands on the apex with a clean 301 |
Five to seven checks cover the realistic failure surface of most stores, and they fit inside the $19 Starter plan with room to spare. The point is coverage of the buying path, not a single ping at the domain.
who owns the failure
Hosted or self-hosted, the gap is yours to watch
Where your store runs changes what you can fix, but not what you should monitor. Either way, most of the failures that stop sales are yours, not the platform's.
Hosted platforms (Shopify, BigCommerce)
You cannot fix a platform outage, and you will usually hear about it from the platform at the same time your monitor does. But the platform's uptime number explicitly excludes theme edits, app errors, third-party services and your custom domain, which is close to a complete list of what actually breaks a store. That gap is entirely yours to watch. We go deep on this in Shopify uptime monitoring.
Self-hosted (WooCommerce, Magento)
You own the whole stack: hosting, PHP, the database, plugins and the cart. That means more can break, and more of it is fixable once you know. A plugin update white-screening the store, a database connection dropping under load, a cron that stopped: all of it needs watching from outside. The specifics for WooCommerce are in how to monitor WooCommerce uptime and checkout.
Understanding what an hour of a stalled storefront costs in lost income is worth doing before you decide how much monitoring is enough. We work through the numbers in how much does website downtime cost.
why us
Why ecommerce teams use AlertPing
Content checks, not just codes
Keyword and body assertions catch the broken cart that still returns 200, which is the failure a plain uptime ping misses on a store.
30-second checks
On a store doing real volume, a five-minute interval is five minutes of orders lost before anyone knows. We check every 30 seconds on every plan.
Three regions agree first
A single flaky hop should not page you at 3am, and a store fine in Virginia but down in Frankfurt should. Three-region confirmation handles both.
SMS in every plan
Outages happen at night and email does not wake anyone. SMS is included and unmetered from $19, with no credit packs to run dry mid-incident.
What monitoring will not do for you
It will not keep your store up during a hosting or platform outage, and it does not simulate a full checkout with a real card, so it is not a substitute for testing your funnel after a big theme or app change. What it does is tell you, within seconds and from outside your own network, the moment a real buyer would hit a wall, so a broken store is measured in minutes rather than discovered from an angry email hours later.
store questions
Ecommerce monitoring questions, answered
What is ecommerce website monitoring?
It is watching an online store from outside your network to confirm real buyers can load products and pay, not just that the server answers. Good ecommerce monitoring checks the storefront, cart, checkout and SSL on a short interval and asserts on page content, so a broken cart that still returns 200 still triggers an alert.
How do I know if my online store is down?
Loading it yourself proves little, since your browser may be cached and you are one location. Run checks from outside that assert on page content rather than the status code, from more than one region, on the homepage, a product page, the cart and checkout. That is the difference between "the server answered" and "a customer could buy."
Can a store return 200 and still be broken?
Yes, and it is common. A broken theme, a failed cart script, a payment tag that did not load, or an "unavailable" billing page can all serve a healthy 200 while orders drop to zero. A content assertion is what separates a page that rendered correctly from one that merely responded.
How often should I check an ecommerce site?
Every 30 to 60 seconds for a store taking real orders. At a five-minute interval an outage can run for minutes before the first failed check even registers. AlertPing checks every 30 seconds on every plan and confirms from three regions before alerting.
Does uptime monitoring cover the checkout?
Only if you point a check at the checkout specifically and assert on its content. Monitoring the homepage alone will not catch a checkout that fails under load, because the two fail independently. Add the checkout URL as its own monitor with a content assertion, separate from the storefront.
Do I need monitoring if my platform has a status page?
Yes. A platform status page reports the platform's global state and excludes store-specific problems: your theme, your apps, your domain, your certificate. Those are the failures that actually stop your sales, and only an external monitor watching your real URLs will catch them.
Know the second a buyer cannot check out
30-second checks on your storefront, product pages, cart, checkout and certificate, confirmed from three regions, with SMS in every plan. Running in under a minute.