Storefront pages
HTTP checks on the home page, a collection, and a best-selling product page, with content assertions on real page text — so a theme break or an app outage that blanks a section fails the check even at HTTP 200.

PageLantern for Shopify
Shopify's edge rate-limits and bot-screens automated traffic — including uptime monitors. A monitor that scores those refusals as downtime will report outages your store never had. PageLantern learned that the hard way, and rebuilt its scoring around it.
A true story
In August 2026, three Shopify storefronts monitored on PageLantern started failing their checks. The stores were fine — customers were browsing and buying the whole time. What actually happened: Shopify's edge had started rate-limiting our probe's egress IP, answering many checks with HTTP 429. Our scoring at the time did what most monitors still do — counted every refused request as a failed check — and for eight days those three storefronts recorded roughly 83% false downtime.
A 429 is the origin saying "I answered, and I decline to serve this particular request." That is evidence about the requester's traffic, not about whether the store is up. Scoring it as downtime is simply wrong, and at Shopify's scale — where the edge routinely throttles datacenter IPs that poll on a schedule — it is wrong constantly. We rebuilt our probe scoring around that incident, and the rebuilt behavior is now on every plan.
What we changed
PageLantern now classifies three kinds of response as inconclusive: a rate-limit refusal (HTTP 429), a bot-protection block, and a bot-protection challenge page. An inconclusive response produces no verdict at all — it is not a failed check, it does not advance an incident, and it does not count against the store's uptime, because nothing about the store was measured.
The discards are bounded so a store that is genuinely down behind a throttle cannot go silently unwatched: after five consecutive inconclusive scheduled checks — about 25 minutes at the default 5-minute interval, far longer than Shopify's short-lived edge throttles need to clear — normal scoring resumes. And when a response carries a vendor's own block signature, proving the origin never saw the request, PageLantern instead opens a probe-blocked incident: a loud alert about our reach, not a false alarm about your uptime. The monitor shows "Not measured" for exactly what it is.
What to watch
Shopify runs the platform, but plenty that customers depend on is still yours to watch — the domain you brought, the certificate on it, the theme's rendered pages, and the services your storefront calls.
HTTP checks on the home page, a collection, and a best-selling product page, with content assertions on real page text — so a theme break or an app outage that blanks a section fails the check even at HTTP 200.
Monitor both the apex and the www host so a broken redirect or a DNS change at your registrar is caught, not discovered from a customer email.
Shopify manages TLS for connected domains, but the certificate customers see is still worth watching independently — an expiry warning costs nothing and renewal failures do happen.
The domain is the one part of a Shopify store that Shopify cannot renew for you. An RDAP expiry check warns before it lapses.
Watch the pages on the path to checkout — cart and the storefront steps before it — so a broken funnel is an alert, not a revenue chart anomaly.
If your theme calls your own APIs or a critical third-party app endpoint, API checks with assertions confirm they answer correctly, not just at all.
Edge reality
Commerce storefronts are the most bot-defended pages on the internet. Between Shopify's own edge and fronting layers like Cloudflare, an external monitor's requests will sooner or later be throttled, challenged, or blocked — and any monitor that pretends otherwise will either invent downtime or report uptime it never measured. PageLantern recognizes vendor signatures for the major protection layers and scores their responses as inconclusive rather than guessing.
The operational states guide documents the whole model — what "Not measured" means, when a probe-blocked incident opens, and how to allowlist the probe by its User-Agent substring (PageLantern-Probe) rather than by IP, which breaks silently when egress addresses change.
At a glance
| What breaks | The check that catches it | Plan |
|---|---|---|
| Storefront down or erroring | HTTP uptime check with expected status codes | Free |
| Theme or app breaks a page that still returns 200 | Content check — body contains / not contains | Free |
| Certificate on your custom domain expires | SSL certificate expiry monitoring | Free |
| Domain registration lapses | Domain expiry / RDAP check | Free |
| Your own API or a critical app endpoint misbehaves | API check with JSONPath assertions | Free |
| Edge rate-limits or challenges the probe | Scored "not measured" — never false downtime | Every plan |
| Storefront journey breaks in a real browser | Hosted browser check with screenshots | Starter ($9/mo) |
Plan shapes are the published plans — Free is 15 monitors at 5-minute checks; Starter is 50 monitors at 1-minute checks.
Plans at a glance
| Limit | Free | Starter | Team |
|---|---|---|---|
| Price | $0 | $9/mo or $7/mo annual | $24/mo or $19/mo annual |
| Monitors | 15 | 50 | 500 |
| Check speed | 5 minutes | 1 minute | 30 seconds for 25 critical monitors |
| Users | 1 | 3 | 10 |
| History | 30 days | 90 days | 1 year |
| Status pages | 1 hosted page | 3 pages | 10 pages |
| SMS alerts | Not included | 50 SMS per month | 200 SMS per month |
| Alert channels | 1 channel | 5 channels | Unlimited |
Figures are the published plans — the full matrix is on the pricing page.
Next step
FAQ
Yes. You monitor a Shopify store from the outside like any site: HTTP and content checks on storefront pages, SSL certificate and domain expiry checks on your custom domain, and API checks for services your storefront depends on. No app install and no theme change — checks run against public URLs.
Almost certainly rate limiting. Shopify's edge throttles automated traffic per IP, and a monitor polling on a schedule from a datacenter address is exactly what it throttles. A monitor that scores the resulting HTTP 429s as failures reports downtime that never happened — we measured roughly 83% false downtime across eight days on three real storefronts before rebuilding our scoring so refusals are "not measured" instead.
No — the discards are bounded. After five consecutive inconclusive scheduled checks (about 25 minutes at the default interval, which comfortably outlasts Shopify's short-lived edge throttles), normal scoring resumes, so a store that is genuinely down still gets reported. And when a response proves a protection layer blocked us, PageLantern opens a probe-blocked incident so the gap in measurement is loud, not silent.
PageLantern watches the funnel up to checkout: storefront, product, and cart pages, plus your domain, certificate, and the services your theme calls. We do not run scripted purchases against a live checkout — Shopify's checkout is aggressively bot-protected, and automating real orders is the wrong tool. Hosted browser checks (paid plans) can walk storefront journeys and capture screenshots as evidence.
Usually not — inconclusive scoring means throttles and challenges do not create false alerts. If our probe is persistently blocked, the monitor shows "Not measured" and a probe-blocked incident tells you. Where you control a fronting layer such as Cloudflare, allowlist by the User-Agent substring PageLantern-Probe, never by IP; the operational states doc has exact rules.