What should be monitored on an ecommerce website

Your uptime monitor says the store is fine. Customers say orders are failing. Both can be true at the same time.

Generic HTTP checks only prove something responded at /. WooCommerce and other ecommerce stacks fail in ways that leave the home page green while checkout, payments, tax, shipping, or inventory sync are broken. Revenue leaks quietly — until someone notices the bank deposits stopped matching the dashboard.

Store monitoring should treat money paths as first-class, not optional add-ons to a brochure-site ping.

Uptime — necessary, not sufficient

Start with external uptime on:

• Home page and a representative product URL.
• Cart and checkout URLs (even if they redirect when empty — you want the route, not a 500).
• /wp-admin/ or your store admin login (catch whole-site fatals early).

Use multiple regions if your customers are geographically spread; CDN edge caching can mask origin failures in a single probe.

Uptime tells you the site is reachable. It does not validate that Add to cart → pay → confirmation email works.

Synthetic checkout and payment health

The highest-value monitor for most WooCommerce stores is a scheduled synthetic purchase in test/sandbox mode:

• Add a known test product to cart.
• Walk through checkout with a Stripe/PayPal/square test transaction (or your gateway’s sandbox).
• Assert order confirmation page and order ID in admin.

Run this daily or after every plugin update. Failures here beat “site up” every time for protecting revenue.

Also watch:

• Payment gateway webhooks — missed webhooks leave orders stuck “pending.”
• SSL on checkout — mixed content or expired certs block browsers from posting card data.
• Third-party checkout scripts (Apple Pay, BNPL widgets) — one blocked CDN URL breaks a payment tab silently.

If your maintenance program is updates only, this is the layer most likely missing — plugin passes do not click Place order.

Cron and background jobs

WooCommerce relies on Action Scheduler and server cron for:

• Order emails and admin notifications.
• Stock reductions and backorder logic.
• Subscription renewals (Woo Subscriptions and similar).
• Feed and ERP sync plugins.

When cron stalls, symptoms look like “random” business problems: emails delayed, subscriptions not renewing, exports stuck.

Monitor:

• Action Scheduler queue depth and oldest pending action age.
• WP-Cron or system cron last-run heartbeat (many hosts disable wp-cron in favor of real cron — know which you use).
• Failed actions log spikes after updates.

A daily admin check is not monitoring. Automate threshold alerts.

Inventory and catalog sync

If stock comes from an external system (POS, warehouse, Amazon, ERP):

• Monitor last successful sync timestamp and row counts.
• Alert on API auth failures before every product shows zero stock or stale availability.
• Spot-check high-velocity SKUs after sync jobs.

Overselling and “everything out of stock” both hurt trust and create support load — often before uptime blinks.

Performance on money pages

Slow checkout is abandoned checkout. Track:

• Time to interactive on product, cart, and checkout templates.
• Cart AJAX add/update failures (JavaScript errors show in browser console — synthetic tests can catch them).
• Database slow query trends on order peaks (Black Friday is not the day to discover missing indexes).

Performance monitoring complements broader maintenance — caching misconfiguration after updates is a common self-inflicted wound.

SSL, domain, and DNS

Stores are high-value targets and browser-sensitive:

• Certificate expiry with 30+ day warning.
• Domain registration expiry — especially if marketing runs on www but checkout is on a subdomain.
• DNSSEC / nameserver changes if you use external DNS.
• HSTS and redirect loops that block mobile checkout.

Brochure sites survive a cert lapse longer than stores; customers hit Proceed anyway less often when money is involved.

Email and transactional delivery

Orders that complete but never email the customer generate chargebacks and support tickets. Monitor:

• SMTP/API quota and bounce rates for order and password-reset mail.
• SPF/DKIM/DMARC alignment after DNS edits (marketing often changes DNS without telling ops).
• A periodic test order email to an inbox you control.

Email failure is invisible to uptime monitors.

Security signals

Ecommerce sites attract card skimmers and fake admin users:

• Unexpected admin account creation.
• New unknown plugins or changed checkout templates.
• File integrity changes in wp-content/plugins/woocommerce or payment plugin directories.
• Spike in failed login attempts on /wp-login.php.

Pair automated scans with human review after any plugin update touching checkout.

Backups and restore — store-specific

Standard backup advice applies, but stores add:

• Order volume — more frequent backups during sales; know your acceptable order loss window.
• Restore verification must include test checkout and payment config — not just home page loads. See restore verification vs backup.
• PCI scope — know what card data never touches your server (ideal) vs what plugins store.

A restore that brings back products but breaks live gateway keys is a failed recovery for commerce.

Alert routing and runbooks

Monitoring without response is a dashboard hobby. Define:

• Who gets paged for checkout down vs email delayed vs SSL expiring.
• Business hours vs after-hours escalation (owner phone, agency ticket, Commerce Systems on-call).
• First steps: disable recent plugin, switch payment gateway to maintenance mode, rollback to last verified backup.

Document gateway support numbers and host ticket paths before you need them.

Minimum viable ecommerce monitor stack

For a small WooCommerce store without enterprise tooling, prioritize in order:

1. External uptime on home, product, cart, checkout.
2. Daily synthetic sandbox checkout.
3. SSL and domain expiry alerts.
4. Cron / Action Scheduler backlog alert.
5. Backup success + quarterly restore test including checkout.

Add ERP/sync and performance depth as revenue and complexity grow.

The practical takeaway

If the only automated check on your store is “is the homepage up,” you are monitoring hosting — not commerce. Checkout, payments, cron, stock, email, and SSL failures are where revenue dies quietly.

Align monitoring with full maintenance ownership — someone must own alerts, runbooks, and fixes. Stores that catch checkout failures in minutes instead of weeks treat monitoring as part of care, not an optional upsell.

Build the signal list above, wire alerts to humans who can act, and test the payment path on a schedule. That is what ecommerce monitoring should include — not a single green dot on an uptime graph.