Be first in. Get early access

CheckoutBeat

All documentation

Checks

The walk

A check is a real Chromium browser, started fresh for each check with no cookies or storage from any earlier check. It identifies itself on every request as CheckoutBeatBot/1.0 (+https://checkoutbeat.com/bot) so you can filter it out of analytics.

  1. Product page. The product URL is opened and must answer with a 2xx status.
  2. Add to cart. The add-to-cart button must be present. On Shopify the first available variant is read from the product's JSON and added through /cart/add.js, the same request your theme makes; on WooCommerce the product form is submitted (or ?add-to-cart=ID is used when the id is known). A sold-out product or a rejected add is a failure with the store's own message.
  3. Cart. The cart must hold the item: Shopify's /cart.js must report at least one item, WooCommerce's /cart/ must show a cart line and no "your cart is empty" notice.
  4. Checkout page. /checkout (Shopify) or /checkout/ (WooCommerce) is opened and must load. The check stops here. Nothing is typed, no shipping or payment details are entered, and no order is ever created. The cart that was used is gone when the browser closes.

Each step has 20 seconds; a whole check has 90. A step that fails ends the check, with a screenshot of the page at that moment.

Bot protection at checkout

Shopify, and Cloudflare in front of many stores, sometimes answer a browser's request for the checkout page with a challenge ("Just a moment…", a captcha, Shopify's "verify that you are not a robot" page) instead of the checkout form. CheckoutBeat never tries to get around that. When it happens:

  • the checkout step is marked skipped and the check stops at the cart, which it has just verified holds your product;
  • the result says "checkout page could not be verified" and the timeline block is amber instead of green;
  • no incident opens and no alert is sent because of the challenge.

The product page, add to cart and cart are still checked every time. If you run your own Cloudflare in front of a WooCommerce store, you can add a WAF skip rule for the user agent above and checkout is verified end to end.

Other platforms

Stores that are neither Shopify nor WooCommerce need a recorded buy path: the selectors of your add-to-cart button, cart line and checkout page. Ask support with the product URL and we set it up with you.

Scheduled and on-demand checks

Scheduled checks run every 60 minutes (Starter) or 30 minutes (Growth, Agency) for every buy path of every store on your plan. They are part of the plan and are not counted anywhere.

An on-demand check is one you start yourself: the Run a check now button, the free check on the home page (not metered, limited per visitor), POST /api/v1/store-check or POST /api/v1/stores/{id}/check from the API, or the MCP tool. On-demand checks count against the monthly allowance shown on the dashboard (1 on the free tier, 100 on Starter, 500 on Growth, 2,000 on Agency). A manual check of a monitored store also feeds its incident state, so after a fix you can confirm and close an incident without waiting for the schedule.

Uptime, SSL and theme

Alongside every check, one plain request to your store URL records the HTTP status and time to first byte and reads the SSL certificate's expiry. The names of the theme's stylesheets and scripts are hashed into a theme fingerprint; when it changes between two checks you get an email saying so, because a published theme is the most common cause of a broken buy path.

What a passed check means

That buy path worked at that moment, from our location, in our browser. It does not see every device, country, payment method, discount code or app, and it does not test the payment step. It is a smoke test that runs all day so the common breakages are noticed within an hour, not when a customer writes in.