Synthetic transaction monitors

Check that a multi-step flow — search, contact form, add to cart — still works end to end.

A synthetic transaction monitor walks through a short sequence of pages the way a visitor would, and checks each step along the way. A homepage that loads tells you the server is on; a transaction tells you the search box still returns results and the contact form still says thank you.

Transaction monitors are available on Pro, Business and MSP, and are counted in steps rather than in monitors — see how the allowance works below.

How it works

You give the monitor up to five steps, in order. Each step is a request to a public URL on your site, and each one can assert what a good response looks like. Cookies carry from one step to the next, so a session started in step 1 is still there in step 2.

The monitor is down the moment a step fails, and the failure names the step — "step 3: page did not contain Thank you" — so you know where the flow broke rather than only that it did.

Setting up a step

Each step has:

  • Method — GET for loading a page, POST for submitting a form.
  • URL — a full public http:// or https:// address.
  • Form fields (POST only) — up to 25 name/value pairs, sent form-encoded or as a JSON body.

Then the checks that step has to pass. All of them are optional:

  • Max status code — anything above it fails the step. Left blank, the step requires a response under 400, the same rule an HTTP monitor uses.
  • Page must contain — text that has to appear in the response, up to 200 characters. Matching is case-insensitive.
  • Page must not contain — text that must be absent. Good for catching an error page that still returns HTTP 200.
  • Max response time — milliseconds, up to 60,000. The step fails if it is slower.

Never put a credential in a step

This monitor is deliberately credential-free. It has nowhere to store a password, an API key, or a token, and it should never be pointed at a flow that needs one. Fill forms with obvious test data — a test name, a sample search term, a message that says it came from monitoring.

Anything you type into a step is stored as configuration and is visible to anyone who can see the monitor.

What it can and can't see

  • It reads the raw response, not a rendered page. There is no browser and no JavaScript engine, so "page must contain" matches what the server sent. Text that only appears after client-side JavaScript runs is invisible to it — assert on something the server renders.
  • Redirects are followed, and each hop is checked for safety the same way the first request is.
  • Each step gets 8 seconds, and the whole transaction is abandoned after 25 seconds. A flow that needs longer than that is too slow to be a monitor.

Your plan's step allowance

Each step is a separate request to your site, so a five-step journey does five times the work of a one-step one. Plans therefore include a total number of steps across every transaction check you have running, rather than a number of transaction checks:

FreeHobbyProBusinessMSP
——25 steps75 steps250 steps

Pro's 25 steps is five 5-step journeys, or twelve 2-step ones, or any mix that adds up. Pausing a transaction returns its steps to the pool. A transaction also counts as one monitor against your plan's monitor limit, like every other check.

If a plan change leaves you over the allowance, the newest transaction checks are paused rather than deleted — the oldest keep running, everything is kept, and a paused one resumes as soon as there is budget for it. See Plans & limits.

How often it runs

A transaction runs no more often than once every 60 seconds, on every plan, including the ones that check everything else every 30 seconds. A transaction can spend up to 25 seconds walking its steps, so a faster interval would start the next run before the last had finished and quietly skip checks. It is a technical limit, not a plan restriction.

Good flows to watch

  • A homepage load that confirms your headline is on the page.
  • A search that confirms results come back with a term you know is in the index.
  • A contact or lead form: load the page, submit test data, confirm the thank-you message.
  • A vendor's public status endpoint your service depends on.
  • Browse to a product and add it to the cart, then abandon it.

Get started

Last updated 2026-10-12