Shopify store monitoring: what should you check?

Availability (uptime) monitoring requests a URL on a schedule and checks the response — is the store returning a normal status code, and how quickly? It is genuinely useful: if your domain, DNS or hosting fails, an availability check tells you the store is unreachable, and it is cheap to run frequently.

Its limit is that it reads a response; it does not perform the actions a shopper does. A Shopify storefront can return a normal HTTP 200 while an Add to Cart button does nothing, so availability monitoring cannot on its own confirm that a customer can buy. It answers "is the server responding?" — not "can a customer reach checkout?"

The purchase path starts on a product page, where a shopper chooses a variant (size, colour, plan) and adds the item to the cart. A browser check can open a product page, select a variant and click Add to Cart, then confirm the item appears in the cart. If the variant picker throws an error, the Add to Cart control stays disabled, or the click does nothing, the check records where it stopped.

What this establishes: that the product and variant you tested could be added to the cart in the browser and viewport you tested. What it does not establish: that every product, every variant and every market behaves the same way. A passing run covers the journeys you configured, not the whole catalogue.

The cart is where discount logic, upsell offers, free-gift rules and bundle builders often run together, each usually a separate app injecting its own scripts. A check can confirm the item reached the cart with the expected quantity, and — if you configure it — apply a discount code and assert the resulting total. That surfaces a cart that errors, fails to update, or does not apply a code as expected.

The limit is scope: a check exercises the cart states you script (for example, one product with one code). It does not prove every combination of products, codes and offers works.

The most revenue-relevant check confirms that the "Checkout" action transitions from the cart to the Shopify checkout page. This is the handoff where theme changes and app conflicts most often surface. See checkout monitoring for how this works step by step.

An important boundary: a test that reaches the checkout page stops there. It does not place an order and does not verify that a card payment can be completed — payment authorisation and capture are outside what the test performs. Reaching checkout is strong evidence the pre-payment path works; it is not proof that a payment will succeed.

Third-party apps add scripts to your storefront and update on their own schedule. Monitoring can detect the storefront scripts that load, notice when one changes, and capture console errors from a real browser. That gives you a record to compare against when a purchase-flow check fails around the same time. See app conflict monitoring.

Two limits matter. First, publicly detected storefront scripts are not a complete list of your installed Shopify apps — some apps run server-side or do not add a detectable script. Second, a changed script or a console error is a clue, not proof that an app caused a failure. Confirm the customer-facing behaviour before assigning a cause.

Manual QA and automated monitoring do different jobs. A person testing before a release can exercise judgement, try edge cases and follow a hunch — but only at the moment they test. Automated monitoring repeats a fixed set of checks on a schedule long after launch, so a regression introduced by a later theme edit or app update is caught without anyone remembering to look. Monitoring complements release QA; it does not replace it.

Revenue Shield focuses on the purchase-flow side: on a schedule, an automated browser opens a product, selects a variant, adds to cart and reaches checkout, running a desktop and a mobile viewport on each cycle. Tests stop before payment, so no orders are placed. When a run fails and a confirmation retry agrees, your team is alerted with the failing step, screenshots and a video recording of the run.

It pairs that with storefront script monitoring so you have context when something breaks. To go deeper: synthetic monitoring for Shopify covers how the browser checks are built and run; checkout monitoring focuses on reaching checkout; app conflict monitoring covers script observations and their limits.