How to monitor a WooCommerce store, where every layer can break on its own

A WooCommerce store looks like one thing from the outside: a website that either loads or doesn't. Underneath, it's eight or nine separate systems, each with its own maintainer, release schedule, and way of failing, and none of them know the others exist. Cassian™ exists because that gap between the two views is where revenue quietly disappears.

The stack you own, and why there's no status page for it

On Shopify or BigCommerce, one company runs the servers, the checkout, the database, and the security patching, and when something breaks there's a single status page to check. WooCommerce doesn't work that way. WooCommerce is a plugin that turns WordPress into a store, which means your store is actually a stack of independent pieces: WordPress core, WooCommerce itself, your theme, every other plugin you've installed, the PHP version your host runs, the database, the web host, the SSL certificate, and DNS. Each one updates on its own schedule, maintained by a different team with no obligation to coordinate with any of the others.

Your host publishes a status page, but it covers the host's infrastructure, not your store. If your host's servers are up, which they usually are, while a plugin update quietly disables your checkout, the host's status page will show all green while your store loses every sale. Ownership is the whole point of WooCommerce, it's why the platform is flexible enough to run almost any kind of business, and it's also why nobody is watching your specific combination of plugins and theme and PHP version except you.

Reachability, admin, and the checkout that plugin updates break

Most owners think of "is my store down" as one question, but it's really two: can customers reach the storefront, and can you reach wp-admin. A tool like UptimeRobot (https://uptimerobot.com/) is well suited to the first question, pinging whatever URLs you give it on a schedule, and its free tier is generous enough for most small stores to run for years without paying anything. Point it at your homepage and a product page and it will tell you fast when either goes dark.

The admin side gets skipped by almost everyone, and it shouldn't. A store whose storefront loads perfectly while wp-admin returns a white screen or a fatal error is a store you cannot fix through the interface you'd normally use to fix it, and a homepage ping will never catch that failure because the homepage is fine. Add a separate check on wp-admin so a broken back end shows up as its own alert, not as a surprise the next time you try to edit a product.

Then there's checkout, which is where plugin updates go to die. The single most common way a WooCommerce store breaks isn't the server going down, it's a caching plugin that starts caching a page it shouldn't, a security plugin that blocks a script WooCommerce needs, or two plugins that work fine individually but conflict once both are active, and checkout stops working while every other page on the site loads normally. A general "is my site up" check will never catch this, because the storefront still returns a healthy response.

Treat every plugin update as an event that needs a checkout test right after it, not just a glance at the homepage. For stores where an hour of broken checkout is expensive, a scripted synthetic test from a tool like Checkly (https://www.checklyhq.com/) can walk through add-to-cart and checkout on a schedule and flag the moment it stops completing. We've covered this exact failure pattern in more depth in Plugin conflicts are the number one way WooCommerce stores break. Cassian watches order flow continuously, so when a plugin update breaks checkout, the drop in completed orders shows up as an alert within the hour rather than at the end of a quiet weekend.

The background jobs no one thinks to check

WooCommerce depends on a scheduling system called Action Scheduler (https://actionscheduler.org/) to run work that shouldn't happen while a customer waits: sending order confirmation emails, processing subscription renewals, syncing stock levels, applying scheduled sales. Action Scheduler rides on WordPress cron, and WordPress cron has an odd quirk worth knowing: it isn't a real system-level scheduler, it's triggered by someone visiting the site. On a busy store that's rarely a problem, since traffic keeps cron firing all day. On a quiet store, especially overnight, cron can go long stretches without firing at all, and the queue of scheduled jobs simply piles up unprocessed.

The result is a store that looks fine, pages load and checkout works, while a growing list of jobs silently fails to run: renewal charges that don't happen, confirmation emails customers never receive, stock counts that drift out of sync with the warehouse. None of it throws an error a customer sees. It shows up later as a confused customer, a chargeback, or a stock-out nobody planned for.

WP Crontrol (https://wordpress.org/plugins/wp-crontrol/) is a free plugin that shows exactly what's scheduled, when it last ran, and whether anything is failing, and it's worth installing on any WooCommerce store even if you only check it once a month. Cassian doesn't inspect the cron queue directly, but it watches the downstream effects, order flow and stock levels among them, so a stalled queue tends to surface as an anomaly before it becomes a pile of angry customers.

Orders, prices, and stock: the signal that catches everything upstream

Every failure described so far, a bad plugin update, a stalled cron queue, a host misconfiguration, tends to produce the same downstream symptom: orders stop, or slow down more than the calendar explains. That makes order flow the single most useful signal on a WooCommerce store, because you don't need to know which of a dozen possible causes is responsible to know that something needs attention right now.

The trick is knowing what normal looks like for your store specifically. A quiet Sunday night is supposed to be quiet, and an alert that fires every weekend just teaches you to ignore alerts, which defeats the purpose. Cassian watches order flow against your store's own pattern for that hour and day of week, so a silent Tuesday morning reads as a problem while a silent Sunday night reads as exactly what it is.

Prices and stock deserve the same outside eye. A bulk price edit, a currency or tax plugin, or an import gone slightly wrong can leave a product priced at $0 or at ten times its usual price with nobody noticing until a customer either takes advantage of it or complains about it. Cassian watches for pricing errors and stock-outs on your top sellers specifically, since those are the products where a mistake costs the most in the shortest amount of time. If you're trying to diagnose a sales drop that's already happened, The 48-hour checklist for diagnosing a sudden drop in store sales walks through where to look first.

Search visibility, security, and the boring infrastructure

A WooCommerce store's visibility depends on things that break quietly too: links that 404 after a product is deleted or a URL structure changes, a sitemap that stops updating, malformed structured data, or a product feed missing fields an AI shopping agent needs to recommend the product at all. None of these stop the store from functioning, and none show up on an uptime check, but each is a slow leak in traffic that usually gets noticed only as "sales are down" weeks later. We've covered the sitemap failure mode specifically in How to tell if your store's sitemap is quietly broken, and the growing importance of feed quality in AI shopping agents are placing real orders.

Security matters more here than on a hosted platform, for the same ownership reason as everything else. WooCommerce runs on WordPress, the most widely deployed content management system in the world, which makes it a standing target for automated attacks, and the usual way in is an out-of-date plugin with a known vulnerability sitting untouched for months. Cassian Shield™ scans a store from the outside for vulnerabilities and header problems, catching exactly the kind of exposure that's invisible until someone exploits it.

Two other things are worth knowing about, both because they can surface plugin incompatibilities without anyone changing anything on purpose. WooCommerce introduced High-Performance Order Storage (https://developer.woocommerce.com/docs/features/high-performance-order-storage/), which moves orders out of the shared WordPress posts tables into dedicated order tables, and it became the default for new installs from WooCommerce 8.2 in October 2023. WooCommerce has also been shifting cart and checkout from shortcode-based pages to block-based ones. Neither is something every store needs to migrate to on any particular deadline, but a plugin that was never updated for either shift can behave in ways that are hard to diagnose.

Then there's the infrastructure layer that has nothing to do with WooCommerce specifically and takes down stores anyway: an SSL certificate that expires because a renewal notice went to spam, a domain that lapses because a card on file expired, or a host that bumps the PHP version during routine maintenance and breaks a plugin that never tested against it. None of these are exotic. All of them are entirely preventable, and all of them are a genuinely common way for an otherwise healthy store to go dark for a day. WordPress's own Site Health tool (https://wordpress.org/documentation/article/site-health-screen/) is built in, free, and worth opening periodically, flagging PHP version issues and missing HTTPS in one screen. Its limit is that it's a snapshot: you get the information when you remember to go look, not when something changes.

Watching from outside the stack

Every tool mentioned so far, including the free ones built into WordPress, has one thing in common: it runs inside the stack it's checking. A monitoring plugin lives on the same server, behind the same PHP version, next to the same theme and plugins that might be the thing that's broken. When the stack goes down hard enough, whatever is watching it goes down too, and the alert that mattered most, the one telling you the site is unreachable, is the one that never gets sent.

Cassian connects to a WooCommerce store over the WooCommerce REST API and watches from outside the stack entirely. There's no plugin to install, nothing extra running on your server, and nothing that goes down when your server does. It checks order flow against your store's own pattern, pricing errors and stock-outs on top sellers, broken links, sitemap health, SEO health, page speed, translation accuracy for multilingual stores, AI product feed quality, and security exposure through Cassian Shield, with uptime monitoring included on paid tiers. The Cassian Score™ (0-100) rolls all of it into one number so you can tell at a glance whether the store needs attention, but the alerts are the actual product: a message the moment something moves outside its normal range, sent to whichever channel you actually check.

The same approach runs on Shopify and BigCommerce, so a WooCommerce store that eventually adds a second platform, or moves to one, isn't starting its monitoring setup over from nothing. You can see how it applies specifically on the WooCommerce monitoring page.

Building a routine, not a one-time check

No single tool watches every layer of a WooCommerce store, and that's fine, because no single company owns every layer either. A sensible setup combines an external uptime check on the storefront and wp-admin, a look at the cron queue after any plugin update, a checkout test as part of your update routine, and continuous monitoring of the signals that catch problems you didn't think to check for: order flow, pricing, stock, security, and search visibility. Cassian is built to be that outside layer, watching a WooCommerce store the way an in-stack plugin can't, because it isn't running inside the thing that might break.