Free
$0 / forever
Get a real checkout journey running before choosing a paid plan.
- 1 browser journey
- Journey checks every 15 minutes
- 20 monitors
- 1 alert channel
Automatically test your entire checkout flow — from cart to confirmation — so you catch issues before your customers do.
No credit card required.
A successful HTTP response is only part of the story. Switch between these example runs to see what a browser journey can reveal.
The page loaded, but the expected “Order confirmed” text was missing. This is the step your team would investigate.
Illustrative demo with sample timings. Switching scenarios does not run a check or send an alert.
Failed step + error + screenshot. See what broke before digging through logs.
You know what a successful checkout looks like. Describe those steps, test the draft, then put it on a schedule.
Use a dedicated test account. Stop at the order summary, or use a payment-provider sandbox to test confirmation without a real charge.
Use visible button names and field labels. Replace the example text with the words your checkout actually uses.
Use Test journey in the creation or edit form to inspect the draft’s result before saving. The test itself sends no monitoring alerts; website actions still happen.
Add an alert channel and a schedule. PylonMon re-checks a failure before paging, so your team gets a confirmed problem to investigate.
click Sign in fill Email = probe@your-store.example fill Password = your-test-password click Continue expect Welcome back click Add to cart click Checkout expect Order summary
This example stops before payment. It is a starting point, not a verified script for every store. CAPTCHA, MFA, and payment challenges may require a different test flow.
Read the journey setup guide →Try your first journey, then add coverage for the customer paths your business depends on.
Get a real checkout journey running before choosing a paid plan.
Cover checkout, login, and other important flows with more frequent checks.
Bring your team into the response as your monitoring grows.
No credit card needed to start free. Compare complete plan limits and features →
A journey performs the actions you give it. Stop before payment for a cart-to-summary check. For an end-to-end purchase, use a dedicated test flow and your payment provider’s test mode. A scheduled journey should never accidentally charge a real card.
An uptime check can confirm that a page responds. A journey interacts with that page and checks the outcome: did sign-in succeed, did the cart open, did the expected confirmation appear? Use both to cover availability and functionality.
Yes. Test journey runs a draft from the creation or edit form without creating a monitor or changing the saved journey. It shows the step results and a screenshot when available. Draft tests require a browser-enabled instance.
The journey result includes the failing step and its error, with a browser screenshot when available. Alert delivery follows the channels and rules you configure. The failing run is re-checked before paging.
Start with the journey documentation, or ask us about your setup. Tell us which flow you want to cover and where it gets complicated.
Start with one journey. See what your customers would see.
click Sign in fill Email = probe@example.com fill Password = hunter2 click Continue expect Welcome back click Add to cart click Checkout expect Order summary
The full reference covers every step, how credentials are stored, what happens when a step fails, and what journeys deliberately do not do.
No selectors to maintain unless you want them. Steps find things by the text a person sees — the button label,
the field's placeholder — and expect waits for the words that prove the step worked. Eight lines
cover most checkouts; css:#id is there for the awkward ones.
A broken checkout for three hours costs more than a year of this. Journeys are included on every plan — one on Free, two on Pro ($9), ten on Team ($49), negotiated on Enterprise — next to uptime, server and cron monitoring, alerting and on-call, at flat prices that never count seats.
The browser runs from our infrastructure, identifies itself as PylonMon in its User-Agent so you can exclude it from analytics, and only ever does what your script says. Use a test account and a test payment method where money moves.
How it works, step by step: the docs. Watching sign-in rather than checkout? Login monitoring.