A robot that tries.
A visitor who did.
Synthetic testing drives your form on a schedule with a scripted browser and reports whether it worked. Real-visitor monitoring watches what happened when an actual person attempted the action, and judges that run. The first tells you a form can work; the second tells you whether it did.
Neither replaces the other, and the honest split is simple: synthetic testing detects earlier and can verify delivery, while real-visitor monitoring reflects real conditions and is the only one that can still help the person who hit the problem.
Last updated 22 sep 2026 · Technical guidance, not a compatibility guarantee.
7 days free, then from $29/month. A payment method is required and $0 is charged today. Cancel before the trial ends and pay nothing.
Six trade-offs, decided rather than hedged.
Each line names the approach that genuinely wins it. Two of the six go to synthetic testing outright, and pretending otherwise would make the other four worth ignoring.
Detects a break with no traffic
Synthetic testing. It runs on a timer whether or not anyone visits, so it finds an overnight break on a quiet page. Real-visitor monitoring has nothing to judge until someone tries.
Confirms the notification arrived
Synthetic testing, when the product checks a mailbox. A script in the browser cannot see your mail server, so no amount of real-visitor observation answers this.
Reflects the visitor's real conditions
Real-visitor monitoring. The failure happens on their device, their browser version, their network, with their consent choices and extensions. A scripted test reproduces one path, chosen in advance.
Can help the person who hit the problem
Real-visitor monitoring, and only it. A scheduled test reports after the fact; the visitor who met the broken form has already left. Observing the live attempt makes it possible to offer that person another route while they are still there.
Adds nothing to your site
Synthetic testing. It runs externally. Real-visitor monitoring needs a script on the page, which is a real cost and a reasonable thing to refuse.
Creates no test data
Real-visitor monitoring. It never submits your form, so nothing false enters your inbox, CRM or conversion reporting. Synthetic submissions have to be tagged and filtered, and that filtering has to keep working.
Watching real visitors is a heavier thing to do.
A scripted test involves no real person. Anything that observes genuine visits has to be specific about what it records, because “we watch your visitors” can mean anything from counting clicks to recording their screen.
What is recorded
The interaction with the action you configured, structural changes on the page, navigation, and the method, path, status and duration of network requests. Timing, device class and a pseudonymous session identifier go with it.
What is not
Not the contents of your form fields. Not request or response bodies. Not authorisation headers. Not page HTML, screenshots or session recordings — none of those features exist in the product.
The one deliberate exception
If a visitor is offered a backup and chooses to fill it in, that form collects what they typed into it — a name, an email, a phone number, a short message. That is a separate form they deliberately completed, and it is stored so you can reply to them. Privacy notice.
The side effect to weigh the other way
Synthetic testing submits real forms. Those entries reach your inbox, your CRM and sometimes your conversion reporting, and someone has to keep filtering them out. It is a smaller privacy question and a larger housekeeping one.
A wrong verdict on a real visitor is worse than no verdict.
A synthetic test that reports a false failure wakes someone up. A real-visitor tool that reports a false failure interrupts a customer who was doing fine. That asymmetry is why the bar is set where it is.
One signal is never enough
A slow click, a vague word on a button, or a page change that cannot be attributed to the action are all insufficient on their own. Several signals have to agree before anything is shown.
Progress lowers confidence
Any evidence that the journey is advancing reduces the failure score rather than increasing it. A learned journey with an observable completion has to reach its final step to count as a success — and until it fails clearly, nothing is offered.
Ambiguity withholds the retry
Where a repeat could duplicate an order or a payment, the safe retry option is withheld even when other backups are offered. Losing an enquiry is recoverable; charging someone twice is not.
Some things are simply not visible
Inside a third-party embed, the browser prevents observation across the boundary, and coverage there is stated with its limit. What is covered.
If you can only add one, add the one that covers your gap.
Most sites already know when the server is down. Far fewer can say whether the last visitor who tried to get in touch actually managed it.