WooCommerce monitoring from cart to WP-Cron
XICTRAQ monitors the shop, cart, checkout and background tasks of your WooCommerce shop and recognises WordPress maintenance mode during updates as a planned pause rather than an outage. The cookieless tracker reads product views, cart and order completion from the markup of the classic WooCommerce templates.
Check these paths first
- Uptime monitoringHomepage with maintenance detection
/ - Uptime monitoringCustomer account, usually excluded from page cache
/mein-konto/ - Script integrityCart: third-party scripts and form targets
/warenkorb/ - Browser monitoringFrom product page via cart to checkout
/kasse/ - Security scanPublicly readable error log
/wp-content/debug.log
Why checking the homepage is not enough for WooCommerce
WooCommerce runs as a plugin inside WordPress, alongside the theme, payment, shipping and other extensions. WooCommerce recommends excluding cart, checkout and customer account from the page cache. If PHP or the database fails, a cached homepage can therefore keep answering while exactly the pages where sales happen are failing.
XICTRAQ therefore spreads the checks across several modules: uptime monitoring with subpages and maintenance detection, browser checks for the path to checkout, heartbeats for WP-Cron and the scheduled actions of WooCommerce, the security scan for exposed files and script integrity for embedded third-party scripts.
The paths on this page apply to a German-language installation, where the pages are usually called /warenkorb/, /kasse/ and /mein-konto/. In English-language installations they are /cart/, /checkout/ and /my-account/. What counts is the address your shop actually uses.
Let browser checks end before the order button so that no real orders are placed, and sign in to the customer account with a dedicated test customer rather than a real customer account.
What typically breaks in WooCommerce shops
Critical error after a plugin update
If a plugin, theme or WordPress update triggers a fatal PHP error, WordPress shows its critical error message and answers with HTTP 500. Uptime monitoring treats status codes outside 200 to 399 as an outage unless it recognises maintenance or bot protection, and reports configured subpages separately. If the response stays at 200 and only part of the page is missing, a keyword check on the monitored URL reports the missing word.
Page cache hides the outage
WooCommerce recommends excluding cart, checkout and customer account from the page cache. If PHP or the database fails, the cached homepage can keep answering with HTTP 200 while these pages fail. Uptime monitoring requests configured subpages such as /mein-konto/ or /warenkorb/ directly and raises a separate alert for a subpage that cannot be reached.
Maintenance mode during an update
While WordPress updates core or active plugins and themes, it usually answers with HTTP 503 and a notice that the site is briefly unavailable for scheduled maintenance. XICTRAQ recognises this page in German and in English as maintenance: outage and content alerts pause, while SSL, domain and blacklist alerts keep running. Start and end are recorded in the changelog. A maintenance page from a plugin that answers with HTTP 200 remains a normal page for monitoring.
Checkout loads, ordering fails
A JavaScript error from a payment or checkout plugin can break the checkout even though every page answers with HTTP 200. A browser check adds a product to the cart, opens the checkout, fills in fields and verifies that expected elements are visible. If a step fails, XICTRAQ raises an alert and, where possible, stores a screenshot of the failed step. In addition, the tracker reports JavaScript errors from real visits with message, file and line.
WP-Cron and scheduled actions stall
WP-Cron checks on every page load whether scheduled tasks are due, and WooCommerce’s Action Scheduler is started by default via WP-Cron and on admin requests. With little traffic, scheduled tasks can be delayed as a result, such as cancelling unpaid orders or delivering webhooks. Trigger WP-Cron from the server cron and append a heartbeat call: if its ping does not arrive within the expected interval plus grace period, XICTRAQ reports the missed run.
Error log or config backup publicly readable
With WP_DEBUG_LOG, WordPress writes errors to wp-content/debug.log by default, and a leftover copy such as wp-config.php.bak can contain the database credentials. The security scan requests such files and lists those that answer with HTTP 200, an exposed wp-config.php.bak as critical. If a server answers every address with 200, the scan skips these requests rather than reporting false findings.
How XICTRAQ recognises WooCommerce
Technology detection reads the HTML and response headers of the monitored page. It first recognises WordPress and then WooCommerce within it, and a change of the detected CMS is recorded in the changelog. Maintenance detection, by contrast, evaluates the response itself, independently of the detected system.
- WordPress by paths such as /wp-content/, /wp-includes/ or /wp-json/ in the source or by the generator tag, WooCommerce additionally by the identifiers woocommerce or wc-blocks.
- XICTRAQ recognises maintenance by a 503 response that carries the WordPress notice about scheduled maintenance in English or German, or a maintenance notice in the page title. A 503 without such a notice and without recognisable bot protection remains an incident.
- If the detected CMS changes, for example when moving from WordPress to another system, XICTRAQ writes a “CMS changed” entry to the changelog.
- If an error page or bot protection comes back instead of the page, XICTRAQ does not assess CMS and shop in that run and does not infer a system change from it. Server and CDN details from the response headers still apply.
What the tracker captures in WooCommerce
The tracker recognises WooCommerce by the script variables wc_add_to_cart_params or woocommerce_params or by an element with the class woocommerce, and reads shop events from the markup of the classic WooCommerce templates. It sets no cookies and, in standard tracking, stores nothing in browser storage. XICTRAQ records shop events if your plan includes e-commerce tracking.
Captured by the tracker on its own
- Page views with referrer and UTM parameters, Web Vitals such as LCP, CLS and INP, and JavaScript errors with message, file and line.
- Product views with product ID, name and category from the product page markup or from its structured product data. The price is the first amount in the markup; with a sale price or a cart total in the header, this can be an amount other than the selling price.
- Add-to-cart clicks: on the product page with product ID, name, quantity and the price as for the product view, in product lists with the product ID, plus add-to-cart clicks in product blocks.
- Quantity changes and removals in the classic cart, reported per item with the final value rather than every intermediate step.
- The cart state in the classic cart: line items with quantity and price plus the totals shown in the totals box.
- The order completion on the order confirmation with total and order number from the classic order overview. If the customer reloads the page, XICTRAQ does not book the same order number as revenue again.
- The start of checkout on a checkout page whose address contains “checkout”, such as /checkout/.
Not captured automatically
- Foreign currencies in automatic detection: the tracker reports order revenue from the order overview as EUR, even if the shop charges in another currency. Pass a different currency through xictraq.revenue().
- Checkout start under /kasse/: automatic detection looks for “checkout” in the address, which the default German checkout address does not contain.
- Quantity changes, removals and cart state in the block-based cart. Detection for these covers only the classic cart.
- Revenue on confirmation pages that do not show the total in the classic WooCommerce order overview.
- Signed-in customers: WordPress itself marks them on the body only with the class logged-in, without a customer number. Linking them needs an identifier, for example a body class set by the theme following the pattern user-id-number, a data-user-id attribute, window.xictraqUser, the xictraq:user-id meta tag or xictraq.identify().
- Tax, shipping and coupon code on the purchase event itself.
- Cancellations and refunds made in the WordPress backend. There is no automatic event for them.
Pass missing values through the JavaScript API: xictraq.checkout("begin") on a checkout under /kasse/, xictraq.revenue(amount, "EUR", orderNumber, { tax, shipping, coupon }) on a confirmation page without the classic order overview, xictraq.identify(customerNumber, { group }) for signed-in customers and xictraq.refund(orderNumber, amount, "EUR") for refunds, amounts in euros.
The right modules for WooCommerce
Frequently asked questions
How do I add the XICTRAQ tracker to a WooCommerce shop?
Add the script tag with your website ID in the data-site attribute to the head of every page, for example via the child theme or a plugin for custom head code. The script loads with defer and sets no cookies. The tracker then recognises WooCommerce by itself and reads product views, cart and order completion from the markup.
Does WordPress maintenance mode during updates trigger an outage alert?
Usually not. In maintenance mode, WordPress answers with HTTP 503 and a notice about scheduled maintenance, and XICTRAQ recognises this combination as maintenance. Outage and content alerts pause, SSL, domain and blacklist alerts stay armed, and start and end are recorded in the changelog. A 503 without a maintenance notice and without recognisable bot protection, on the other hand, is treated as an incident, because an overloaded server answers the same way.
Which subpages should I also monitor for WooCommerce?
Above all the cart and the customer account, usually /warenkorb/ and /mein-konto/ in German-language installations. WooCommerce recommends excluding them from the page cache, so they usually reveal an error that a cached homepage hides. Uptime monitoring reports each configured subpage separately, and how many paths are possible depends on the plan. The checkout is better checked with a browser check that first adds a product to the cart.
How do I monitor WP-Cron and the scheduled actions of WooCommerce?
With a heartbeat: disable WP-Cron with DISABLE_WP_CRON in wp-config.php, trigger it from the server cron, for example with wp cron event run --due-now, and call the heartbeat’s ping URL afterwards. If the ping does not arrive within the expected interval plus grace period, XICTRAQ reports the missed run. Separate URLs for start and failure also capture run time and aborts. The ping does not show whether individual actions in the Action Scheduler fail; it confirms the run itself.
Does XICTRAQ check the payment scripts in the WooCommerce checkout?
If your plan includes script integrity, it records the SHA-256 hash of up to twelve external scripts embedded on the scanned page when your verified website is scanned, and reports when a script changes later. If you scan a path such as /warenkorb/ or /kasse/, it also watches for new external form targets. Scripts served from the shop’s own domain, including WooCommerce itself and locally installed plugins, are not part of this check, and neither are inline scripts.
Does the tracker also capture the block-based cart and checkout?
Partly. It captures add-to-cart clicks in product blocks, but reads quantity changes, removals and the cart state only from the classic cart. It reports checkout start when the address contains “checkout” and an element with the class woocommerce-checkout is present, and revenue only from the classic order overview on the confirmation page. Where this does not apply, call xictraq.checkout("begin") and xictraq.revenue() yourself.