Shopify’s own status page will be green. The theme will load. An uptime check will get a 200 from the storefront all night. None of that tells you the “Check out” button stopped working after last night’s app update, and the first person who finds out is a customer — or, if you run the store for a client, the client. Here is how to have a browser try the checkout for you, every few minutes, in a way that does not fill the order list with junk.
Every one of those returns a healthy HTTP status. The only check that catches them is one that does what a customer does.
A journey is a real browser, so it can go as far into the checkout as you let it. Decide how far before you write a single step. There are three sensible stopping points.
| Level | What the journey does | Safe on |
|---|---|---|
| 1 · Reach checkout | Add to cart, open checkout, confirm the contact and payment sections rendered. Never submits. | Any live store. This is the one to start with. |
| 2 · Free test order | A hidden $0 test product plus a 100%-off discount code; the order completes and is auto-tagged for cleanup. | Live stores where you control the catalog and can archive test orders. |
| 3 · Bogus Gateway | Completes a full paid checkout with Shopify’s test gateway. | Development and password-protected stores only. Never on a store taking money. |
Level 1 catches nearly everything on the list above — broken cart buttons, dead apps, checkouts that will not load — without touching an order. Only go further when the client specifically cares about the payment step.
Create a product called something like Monitoring probe, price $0, inventory tracking off, and make it unavailable in the Online Store sales channel if you do not want it discoverable. A journey can still reach it by URL. For Level 2 add a discount code (say PROBE100, 100% off, limited to that product) so an order completes at $0 with no card step.
Then create a test customer email on a domain you control, for example probe@yourdomain.example. Shopify will send abandoned-checkout emails to whatever address the journey types, so either turn those off for that address or point it at a mailbox nobody reads.
In PylonMon, add a monitor of type Customer journey, give it the store URL, and paste a script. One step per line, in the words a person sees on the page. This is Level 1:
goto /products/monitoring-probe click Add to cart click Check out expect Contact fill Email = probe@yourdomain.example expect Payment
click finds a button or link by its visible text, so “Add to cart” and “Check out” are whatever your theme labels them; copy the words from the storefront. expect waits up to fifteen seconds for text to appear, which is how you assert the checkout actually rendered its sections rather than a spinner. If a theme uses an icon-only button, click css:#CartDrawer-Checkout works too.
Level 2 continues from there:
fill First name = Probe fill Last name = Monitor fill Address = 1 Test Street fill City = Roseville fill ZIP code = 95678 fill Discount code = PROBE100 click Apply click Complete order expect Thank you
Field names come from the checkout’s labels and placeholders. If the store collects a phone number or ships only to some regions, add those lines; the journey fails on the first field it cannot find and names it, so a missing line is a two-minute fix, not a mystery.
Level 3 is the same script with a card. On a development store with the Bogus Gateway enabled, a card number of 1 is approved; that is Shopify’s documented test card, and it only exists on stores that are not taking real payments.
Set the period. Five minutes is the fastest on paid plans (the free plan walks a journey every fifteen). Every failure is re-checked immediately before anyone hears about it, so a single slow load never pages. Then pick the channel: the client’s Slack, your own on-call rotation, an SMS at night. If you run several stores, put each journey under the client’s tag and give each client a public status page — that page is what you send when they ask whether the site was down.
The monitor page shows every step with its timing. When one fails you get the step, the reason, and a screenshot of the page at that moment:
· goto /products/monitoring-probe 1.4s 1 click Add to cart 612ms 2 click Check out 4ms nothing on the page matches "Check out" 3 expect Contact — last run 41s ago · failed · 2.1s · screenshot attached
That is the alert too: the failing step and the screenshot, not “site down”. A theme update that renamed the button, an app that hid it, a checkout that never rendered its payment section — each one reads differently in the screenshot, and the person on call knows what to open before they have opened anything.
expect Contact be the assertion, or ask Shopify support about allow-listing the probe’s User-Agent, which identifies itself as PylonMon.fill are stored encrypted and never shown again, which is what makes a password-protected store safe to monitor: fill Password = … followed by click Enter as the first two lines.A journey is included on every PylonMon plan — one on Free, five on Pro at $9, twenty on Team at $30 — next to uptime, server and cron monitoring, alerting and on-call, at a flat price that never counts seats or meters browser runs. A checkout that is broken for three hours on a Friday night costs more than a year of that.
The step language in full: the docs. The page for store owners: checkout monitoring.