Synthetic monitoring for ecommerce

What a test purchase tells you that analytics cannot

Analytics records what happened to the people who arrived. When an add to cart button stops working, it shows up as a dip in a chart some days later, mixed in with everything else that moves a chart.

A synthetic check is a purchase you run yourself, on purpose, on a schedule. When it fails, the failure has a date, a step and a screenshot. And there is now a second kind of visitor it stands in for: an AI agent shopping for somebody does not complain when it gets stuck. It goes to the next store. Why that failure is silent.

Three kinds of check, three different questions

Most stores already run one of these. They answer different questions, and a green result on one says nothing about the others.

• An uptime check asks whether the page answers. It is the right tool for a store that is down.
• A scripted synthetic check asks whether one fixed path still works. It fails when a button is renamed, even if a shopper could still buy, and it passes a page that lost its price unless a step was written to look.
• Ottom asks whether an agent can find a product, judge it, compare it and get it to the payment step, and names the stage and step where it stalled.

How Ottom runs a check

Each scan has four stages. Discover, evaluate and compare read what your store publishes for machines: robots.txt, sitemaps, product feeds, structured data, product pages and policies, as an agent can read them without running the page. Rules decide what they can, and a language model judges only what rules cannot settle.

The buy stage is a browser walking the purchase path on your live store, one step at a time. By default a script walks every step first, because most of what ends a purchase is mechanical. Where the script stops, an AI agent takes over that one step and tries to get past it. Before a stall is reported, an AI agent walks the store again on its own, and the further of the two walks is the result.

Every walk stops at the payment step. No card details are entered, no order is placed, and the agent never signs in or creates an account. Our agents identify themselves on every visit, with a published user agent.

What monitoring adds to a single scan

A free scan tells you where your store stands today. Coverage, Monitor, Defend, Patrol and Enterprise repeat it without being asked. Price, stock, structured data and policy checks run every day on every paid plan, and a full agent journey runs every month on Coverage, every week on Monitor, every day on Defend, twice a day on Patrol.

When something changes you hear about it by email, and in Slack if you add a webhook: a score drop of more than 5 points that is also beyond the run to run variation, a new Critical finding once two signals agree on it, a fix confirmed after two clean scans, and a weekly digest. What each alert means.

Your score history keeps which stage stalled in each scan and which findings appeared and cleared between one scan and the next, so you can see the day something changed.

What it does not do

• It is not an uptime monitor. It runs on a schedule, not every minute, so keep the uptime check you have.
• It never pays, so it cannot tell you whether a card would have been accepted. It tells you whether a shopper could get as far as paying.
• It never signs in, so pages behind a customer account are not tested.
• A store accepts at most 12 retrieval checks and 3 full agent journeys a day from Ottom, counted across everyone who asks rather than per customer.