An uptime check tells you the server answered. A journey tells you a customer could sign in, add to cart and reach the order summary. This page is the reference for what that actually involves — including the parts we do not do, because you should know before you buy rather than after.
Seven operations, one per line. That is the whole vocabulary, deliberately:
| Step | What it does |
|---|---|
goto /cart | Navigate. Relative to the start URL, or an absolute URL. |
click Add to cart | Click the element whose text or label matches. |
fill Email = you@example.com | Type into the field whose label, placeholder or name matches. |
expect Order confirmed | Wait up to 15 seconds for that text to appear. |
absent Error | Assert the text is not on the page. |
wait 3 | Pause N seconds. |
screenshot | Keep a picture at this point, not only on failure. |
Targets are matched by visible text, label, placeholder or name — the things a person would use to find the control. When that is ambiguous, give it a CSS selector instead: click css:#buy.
Journeys that matter usually need an account, so this is worth being precise about.
A fill value is sealed with AES-256-GCM before it is stored. The ciphertext is what rides the state document and what comes back on every API response — the value is opened at exactly one moment, when the run is handed to the browser. In the portal and over the API you see a mask, never the password.
Editing the script does not mean re-typing it: send the mask back and the stored value is kept. That also means the mask itself can never be saved as the password by accident.
Two honest notes. Encryption is keyed by an instance secret, and an instance without one stores values in plain text and says so in its log at boot — it can never silently believe it is encrypting when it is not. On pylonmon.com the key is configured, so your values are sealed. And use a dedicated test account with the least privilege that still exercises the flow, not a real customer’s or an administrator’s.
The monitor goes DOWN through the ordinary pipeline — the same immediate re-check, the same escalation ladder, the same incident and status page as any other monitor. What makes the page useful is what rides with it:
expect waits up to 15 seconds for text to appear — the allowance for a page that renders after its data loads.There is no per-step retry loop. The re-check is at the monitor level: a failed run is confirmed before it pages, which is what stops one unlucky render from waking anyone. If a flow is genuinely flaky, a wait before the fragile step is the honest fix, not a longer timeout.
| Plan | Journeys | Fastest cadence |
|---|---|---|
| Free | 1 | every 15 minutes |
| Pro | 2 | every 5 minutes |
| Team | 10 | every 5 minutes |
| Enterprise | up to 100 | every 5 minutes |
Any paid plan can add +5 journeys for $10/month, prepaid. Runs are not billed individually — there is no per-run charge and no overage, so a journey that runs every five minutes costs the same as one that runs every hour.
The part worth reading twice.
A headless Chromium driven over the DevTools protocol, on a dedicated runner — never on the nodes doing the watching, because a machine launching a browser is not a machine you want holding your alerting. The browser is launched for the run and killed afterwards.
Not every page. The one flow where a silent failure costs you: sign-in for a SaaS, add-to-cart-through-checkout for a shop, the quote form for a service business. One journey on the thing that matters beats twelve on pages nobody completes.
The free plan includes one journey at a fifteen-minute cadence, which is enough to find out whether yours is walkable.
Checkout monitoring · Login monitoring · Documentation · A Shopify checkout, end to end