Checkout Monitor

Loading…

Checking…

What one check does

A real headless Chrome opens the page, waits for our checkout to render, loads Whop's elements.js, and then watches the Whop payment iframe. It starts at 0px tall and only grows (to ~574px) once the card fields have actually drawn. A page passes only when that happens, the error box stays hidden, and Complete Order is visible.

Two-step A2A checkouts get filled in with a test identity and clicked through to step 2 first, with the contact API blocked so no abandoned cart or CRM record is created.

How to read a status

  • Healthy: payment fields rendered in under 10s.
  • Slow: rendered, but took over 10s. Buyers on weak connections may give up.
  • Down: confirmed on two attempts 20s apart. The reason column says why (Cloudflare challenge, script blocked, iframe never rendered, error shown to buyer, page 4xx/5xx).

Bars in the history strip are one check each, newest on the right.

What it can't see

Checks run from a cloud runner. Yesterday's failure also hit home and office networks specifically, so a green board here plus customer reports means: believe the customers. The daily 9am ET Slack summary proves the monitor itself is alive; if it stops arriving, the monitor is broken, not the checkout.

Pages are listed in pages.json. Add or pause one there.