Check that customers can reach Shopify checkout

A run drives an automated browser through your configured purchase flow and asserts the outcome at each step, so a failure records exactly where it stopped:

Reaching checkout is where the run ends. It is strong evidence the pre-payment path works, but it is not proof that a payment can be completed — see the limitations below.

An alert that only says "checkout failed" creates urgency without direction. On a confirmed failure, Revenue Shield stores a video recording of the run, a Playwright trace and screenshots, and names the step where the run stopped. That lets your team review what the browser did rather than guess. Merchants are alerted by email, with SMS available on eligible plans.

Each run executes a desktop viewport and a mobile viewport in sequence, because some failures only appear at one size — for example a sticky bar covering the checkout control on a narrow screen. These are responsive browser viewports, not real physical devices, so a run reflects how the site behaves at those viewport sizes in an automated browser.

Release QA checks the store at the moment someone tests it. Scheduled monitoring repeats the same checks afterwards, so a regression introduced by a later theme edit or an app update is caught without anyone remembering to look. Monitoring complements your QA process; it does not replace the judgement a person applies before a release.

When you install the Shopify app, Revenue Shield generates purchase-flow tests for your store — product-page checkout, homepage-to-checkout and buy-now flows (up to three). Each generated test is validated on desktop and mobile before it goes live. You review the flows in the app and start monitoring; there are no browser scripts to write by hand. For the wider technique, see synthetic monitoring for Shopify.

How often a flow runs depends on your plan:

• Free — one purchase flow, checked 3 times daily (approximately every 8 hours), email and Slack alerts.
• Starter and Growth — up to three flows, checks as often as hourly; Growth adds SMS alerts and CSV export.
• Top tier — cadence down to every 15 minutes, plus webhook alerts and AI console-log analysis.

Alert timing is the check interval plus the run duration plus a confirmation step: a first failure moves the test to an investigating state and an automatic retry runs a few minutes later, and the alert fires once the failure is confirmed rather than on a single raw failure. So the alert follows a detected failure on the schedule you chose — it is not instantaneous.

A passing run establishes that the flow, viewports and environment you tested worked at that time. It does not prove that every product, variant, market or customer session works, and — because the test stops before payment — it does not verify that a card payment can be completed. Publicly detected storefront scripts are also not a complete list of your installed apps. Treat a passing run as coverage of what you tested, not a guarantee of the whole store.