Magento monitoring from cron to checkout
XICTRAQ checks cart, checkout, APIs and cron runs of your Magento shop and reports when an embedded third-party script changes its content. What the cookieless tracker captures in Magento on its own, and what it does not, is listed further down.
Check these Magento paths first
- Uptime monitoringCart page, not served from page cache
/checkout/cart/ - Uptime monitoringCustomer login page
/customer/account/login/ - Uptime monitoringCatalog search with a search term
/catalogsearch/result/?q=test - Browser monitoringFrom product page via cart to checkout
/checkout/ - API monitoringREST API without token, with JSON check
/rest/V1/directory/currency - API monitoringGraphQL storeConfig query via POST
/graphql
Why the homepage alone says little about your shop
Magento serves many pages from its page cache. According to the vendor documentation, cart and checkout are not among them: they are generated on every request. A cached homepage can therefore still respond while the cart already shows an error.
Then there is cron. Indexing, catalog price rules, currency rates, newsletters and – with asynchronous sending switched on – order confirmations run through bin/magento cron:run, among other things. If it stops, the shop stays reachable – and a plain availability check sees none of it.
XICTRAQ therefore spreads the checks across several modules: uptime monitoring with subpages for cart, login and search, browser checks for the path to checkout, API checks for REST and GraphQL, a heartbeat for cron and script integrity for externally embedded scripts.
XICTRAQ treats Magento maintenance mode (bin/magento maintenance:enable) as an outage: the default page answers with HTTP 503 and contains none of the maintenance phrases the check node uses to recognise planned maintenance. Create a maintenance window for deployments – outage and subpage alerts stay silent during it.
Where Magento shops break – and which module notices
Maintenance mode stays on after a deployment
If a deployment aborts, the file var/.maintenance.flag stays in place and the shop keeps showing the maintenance page. Uptime monitoring treats this response as an outage and alerts when no maintenance window is active.
Cron stops running
After a server move, a PHP change or a deleted crontab entry, bin/magento cron:run no longer runs. A heartbeat ping after the call then goes missing and XICTRAQ reports a missed heartbeat; calling the /fail address triggers a failure alert.
Checkout breaks after an update
An extension or theme update changes the checkout and the shipping or payment selection no longer loads. A browser check set up for this adds an item to the cart, opens checkout and verifies that the expected elements appear, without submitting the order. If a step fails, it stores a screenshot of that point.
Cart fails, homepage does not
The homepage can keep responding from the page cache while cart or customer account return an error, for example after a database problem or a broken extension. XICTRAQ checks monitored subpages on every uptime run; if one fails, a separate alert names the affected path.
A third-party script changes its content
Web skimming, often called Magecart, targets payment data in checkout. Script integrity stores the SHA-256 hash of externally embedded scripts and reports when one changes or becomes unreachable; a live scan of the cart page additionally reports new third-party form targets. This is an indication, not conclusive proof of security.
REST or GraphQL API returns errors
ERP, marketplace connections or a headless frontend depend on the Magento API. An API check calls the endpoint and verifies status code, response time and content via JSON path or JSON schema; if the response deviates twice in a row, an alert follows.
How XICTRAQ recognises Magento
Magento is recognised in two places: in the live scan and in the tracker. This determines what appears in the technology overview, the CRA cockpit and analytics.
- The live scan recognises Magento by addresses containing /static/version in the page source. Magento adds this version marker when static file signing is enabled, which is the default setting.
- The ongoing technology detection on the check nodes does not include Magento. If it finds nothing, however, a Magento finding from the live scan stays in place.
- The tracker recognises Magento pages by script blocks of type text/x-magento-init, by the product page’s body class catalog-product-view or by the class product-info-main together with RequireJS, and then reads product, add-to-cart click and order completion from the markup.
- In the CRA component cockpit, Magento appears without a version number and is therefore marked as not assessable. There is no matching against vendor security advisories for Magento.
- Hyvä themes and headless frontends such as PWA Studio differ from the Luma markup. The tracker’s selectors do not work reliably there; you then pass product, cart and purchase events through the JavaScript API.
What the tracker captures in Magento
In the default Luma theme, the cookieless tracker reads product, add-to-cart click and order completion straight from the markup. The Luma success page shows no amount, so the tracker reports the purchase there with an amount of 0. An amount passed via dataLayer or the JavaScript API only reaches analytics with limitations.
Captured by the tracker on its own
- Page views with referrer and UTM parameters, plus Web Vitals such as LCP and CLS
- Product views with product ID, name and final price, plus SKU and category from the breadcrumb navigation where present in the markup
- Clicks on “Add to Cart” (#product-addtocart-button and .tocart) as a cart event
- Checkout start on paths containing “checkout” – this already includes the cart page /checkout/cart/
- Order completion on the success page (.checkout-success), with order number for signed-in customers
- Image views in the product gallery of the Luma theme: clicks on an image and image changes via the thumbnails, each with image URL and alt text, shown in the session history as “Image viewed” and “Gallery changed”
- JavaScript errors from real visits with message, file and line
Not captured automatically
- A reliable revenue amount: Luma shows none on the success page, and the tracker reports the purchase there with an amount of 0 – even when an amount arrives via dataLayer or the JavaScript API
- Order number for guest orders: Luma outputs it there without the element the tracker reads
- Signed-in customers: the tracker has no Magento-specific way to recognise them
- Quantity changes and removed items on the cart page: the Luma rows do not match the tracker’s selectors
- Whether an item actually made it into the cart: the click on the button is what gets counted
- Refunds and credit memos: they are created in the Magento backend, not in the customer’s browser
Pass missing values through the JavaScript API once the tracker has loaded: xictraq.revenue(amount, "EUR", orderNumber, { tax, shipping }) on the success page, xictraq.identify(customerId, { name }) for signed-in customers and xictraq.cart("remove", { id, name, price, quantity }) for removed items. In Magento, customer data does not belong in a page served from the page cache, so determine the customer ID for identify in the browser. On the Luma success page, the automatic detection additionally reports a purchase with an amount of 0: for the same order number only one of the two reports counts, and if both arrive within the same second, which one cannot be predicted; without an order number, for example for guest orders, both count. After adding the call, check in analytics that amount and number of orders are correct.
The right modules for Magento
Frequently asked questions
Does XICTRAQ treat Magento maintenance mode as an outage?
Yes. The default Magento maintenance page answers with HTTP 503 and contains none of the maintenance phrases XICTRAQ uses to recognise planned maintenance. Create a one-off or weekly recurring maintenance window for deployments, and outage and subpage alerts stay silent during that period.
How do I monitor the Magento cron?
Create a heartbeat in XICTRAQ with the schedule of your crontab entry and call its ping address after bin/magento cron:run. If the ping is missing, XICTRAQ reports a missed heartbeat; the /start and /fail addresses additionally report the start and failure of a run. The ping shows that cron:run ran, not that every single Magento job succeeded.
Does XICTRAQ detect a Magecart attack?
Partly. Script integrity reports when an externally embedded script changes, and a live scan of a cart or checkout page reports new third-party form targets. It does not report a newly added script, and it does not cover code directly in the page source, files your shop serves itself under /static/ or scripts loaded later in the browser. The check is an indication, not conclusive proof of security.
Does XICTRAQ check my Magento version for vulnerabilities?
No. The live scan recognises Magento but does not read a version number, and there is no matching against security advisories for Magento. The security scan checks general points such as security headers, TLS and exposed files like .git/config, .env or SQL dumps. In case the web root points to the project folder instead of pub, it also requests var/log/system.log, var/log/exception.log and the Composer credentials in auth.json, and only reports a file if its content matches. Installing the vendor’s security updates remains the job of your team or agency.
Why does analytics show no revenue for Magento orders?
The success page of the default Luma theme shows only the order number, not the amount, so the tracker reports the purchase there with an amount of 0. An amount comes from a purchase event with ecommerce.value in the dataLayer or from a call to xictraq.revenue() on the success page, but the report with an amount of 0 remains. For the same order number only one of the two counts, and which one cannot be reliably predicted; without an order number both count. So after adding it, check that amount and number of orders match in analytics.
Does this work with Hyvä or a headless frontend?
Uptime, API and heartbeat checks work independently of the frontend, and browser checks test the selectors you define yourself. The tracker is built around the Luma markup; with Hyvä or PWA Studio its selectors do not work reliably. There you pass product, cart and purchase events through xictraq.product(), xictraq.cart() and xictraq.revenue(). Analytics counts at most one product view per session and page within a minute, so alongside an automatically detected view only the first one received counts.