---
title: Synthetic transaction monitors
description: Check that a multi-step flow — search, contact form, add to cart — still works end to end.
category: monitors
updated: 2026-10-12
tags: [transaction, synthetic, journey, form, checkout]
---

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](#your-plans-step-allowance) 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:

| Free | Hobby | Pro | Business | MSP |
|---|---|---|---|---|
| — | — | 25 steps | 75 steps | 250 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](/docs/account/plans-and-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

- [Create your first monitor](/docs/getting-started/quickstart)
- [Set alert thresholds](/docs/configuration/alert-thresholds)

## Related

- [HTTP / website monitors](/docs/monitors/http)
- [Monitor types](/docs/monitors/overview)
- [Plans & limits](/docs/account/plans-and-limits)