Questions, answered straight.

An uptime monitor tells you a URL responded. Shopcheck drives a real browser through the buyer journey — browse, product, add to cart, checkout — and tells you whether somebody could still buy something. The point is to catch a broken cart before a real customer does.

Page availability and content, multi-step buyer journeys in a real browser, Shopify Admin data such as metafields, collections, navigation and discounts, and heartbeats for your own scheduled jobs. Alongside that it measures Core Web Vitals from synthetic runs, real visitors and Google's field data.

Yes. Any monitor can run against desktop, tablet and mobile, and each device is a separate check with its own history — so a mobile-only breakage shows up as exactly that. You do not need to duplicate the monitor per device.

Not unless you build a journey that does. The usual pattern is to walk browse → product → add to cart → open checkout and assert the checkout page loaded with the right line item. That covers the whole path where breakage happens and stops before it creates data you have to clean up.

No, deliberately. When a step stops matching, the page is re-scanned and a replacement selector is proposed for you to approve. A selector that heals itself onto the wrong element turns a monitor into a check of something else, and reports green while your cart is broken — worse than a monitor that fails.

Raise the failure threshold on that monitor. An incident opens after the number of consecutive failures you choose, and closes after the number of consecutive passes you choose. You can also set a severity per monitor and quiet hours per store.

Email, Slack, or a webhook into your own systems. Webhooks are signed with HMAC over the request body so you can verify the request came from Shopcheck before acting on it.

The failing step, a screenshot of it, the technical detail — response, timings, the assertion that failed — and any remediation note you added to the monitor. Optionally it can also carry an estimated revenue impact and a plain-English root cause derived from that evidence.

Yes, with quiet hours per store. Incidents are still opened and still visible in the dashboard during quiet hours — the notification is suppressed, not the check.

Because they are measuring different things. Shopcheck shows three sources side by side: synthetic (our own browser runs, repeatable), field (real visitors to your store, via a theme app extension), and Google CrUX (the dataset that affects ranking). Disagreement between them is information, not error.

No. Shopcheck is fixed monthly tiers with a usage allowance included — not metered infrastructure. There is no per-browser-minute or per-screenshot charge. Billing a reliability feature by the run makes people reduce frequency, and a check that runs rarely finds out late.

Buyer-journey runs, because they drive a real browser: each plan includes a monthly allowance of browser minutes (450 on Essential, 750 on Growth, 1,500 on Scale). Uptime, content, API and store-data checks never use them, and heartbeats are free. Two things multiply journey usage: device profiles (three devices is three runs) and frequency (hourly instead of daily is 24 times the usage). Extra advanced monitors share your plan's browser minutes.

Buyer journeys pause until your Shopify billing cycle renews and every other monitor keeps running. Skipped journeys are recorded as skipped with the reason, never shown as passing, and the Billing page shows the limit as reached — a monitoring product that quietly stops monitoring is worse than none, because you still believe you are covered.

Yes, whenever your monitoring changes. Your monitors, history and visual baselines are unaffected by a plan change. Charges appear on your Shopify invoice, so there is no separate card to store.

At install: read_products (product and catalogue checks), read_themes (theme and app-embed checks, and the theme-publish webhook), and read_customer_events (the performance telemetry extension). read_orders is requested later, only if you enable order-based revenue impact — declining it leaves everything else working.

Check results, screenshots from browser runs (the failing step, or every step if you choose), visual-regression baselines, a session recording of each Run test, aggregated performance telemetry, and your monitor configuration. Screenshots and recordings live in Cloudflare R2.

They capture whatever was on the page. If you build a journey that logs into a real customer account or types real personal details into a form, that content is in the screenshot and the recording — so use test data in journey steps. The theme extension is separate: it reports Core Web Vitals and funnel events, not session replay of your visitors.

Shopify revokes the access token immediately, so no further checks run against your store.