Synthetic monitoring
HostTracker's synthetic monitoring drives your site on a schedule, from 300+ locations, using whichever check fits the job: a scripted browser journey, an API call judged by rules, or a plain HTTP request. Pick one below and get alerted the moment it stops matching what you expect.
The same shape behind all three: run, judge, recheck, alert
Synthetic monitoring means the traffic is generated on purpose. Instead of waiting for a real visitor to run into a problem, a monitoring service drives your website itself, on a fixed schedule, from outside your network, and checks what comes back against rules you set. HostTracker's synthetic monitoring tools cover three shapes of check - browser monitoring for a scripted journey, an API call judged by rules, and a plain HTTP request - covering everything from a full checkout flow down to a single status-code probe, all from 300+ locations worldwide.
It is not real user monitoring. HostTracker generates every check itself; it does not collect timing or error data from your actual visitors' browsers. If you need to know what your real visitors experienced, that is a different discipline with a different name - see synthetic vs real user monitoring for the full comparison. Synthetic monitoring's advantage runs the other way: it works before you have a single visitor, and it keeps working at three in the morning when nobody is looking.
The three check types answer different questions, and picking the wrong one is the most common way a real problem goes undetected. This table maps five common needs to the check that actually covers them.
Most accounts end up running more than one row of this table at once - an HTTP check under everything, plus a transaction or API check on the one or two flows that matter most.
A transaction scenario is a sequence of named actions; an API rule bundle is a set of assertions over one response. Both are configured, never scripted.
Transaction: a five-step scenario
0 navigate https://shop.example.com/ 1.4 s 1 type #email "[email protected]" 0.2 s 2 click #add-to-cart 0.9 s 3 waitForNavigation /checkout 1.1 s 4 checkContent "Order summary" present 0.1 s
API: a four-rule bundle
status isOk header("Content-Type") contains "json" body.json.path("$.count") gt 0 time lt 5s
Each one answers a different question. Most accounts that use HostTracker end up running more than one.
Open a real Chromium browser and walk up to ten steps - log in, search, add to cart, check out - then assert on what is on the page. Catches what a status code cannot: a removed button, a broken form post, a JavaScript error partway through. Transaction monitoring
Send one HTTP call and judge the response against up to 20 assertion rules over its status, headers, timing and JSON, XML or plain-text body. Built for the endpoint another system depends on. API monitoring
Request a URL from 300+ checkpoints in 158 cities and check the status, body keywords, response time and TLS. The always-on baseline the other two sit on top of. HTTP monitoring
The check shape changes; the checkpoints, the confirmation logic and the alert channels behind it do not.
Every check type runs from the same public checkpoint fleet. Pick the locations that match where your visitors, or your API's consumers, actually are.
A single failing checkpoint never opens an incident by itself. The check is re-run from other, independent checkpoints, and only an agreeing result turns it into an alert.
A transaction check keeps a screenshot of the final step, and another at the moment a step fails, so debugging starts with what the page actually looked like.
Assert on rendered text, a JSON value selected by JSONPath or XPath, or a plain keyword - up to 20 assertion rules or 10 keyword matches per monitor, depending on the check type.
Email, SMS, voice call, Slack, Telegram and webhooks, set up once per contact, are shared across the transaction, API and HTTP checks on your account.
Add any monitor - browser journey, API call or HTTP check - to the same public status page, so customers see one page instead of three separate ones.
Websites, servers, APIs, certificates. One check type per page, the same locations, alerts and reports behind all of them.
Trusted by teams at
Every chapter opens in place, so the page stays short.
The two approaches answer different questions. Synthetic website monitoring generates its own traffic, from its own checkpoints, on a schedule you control - a scripted browser journey, an API call, or a plain HTTP request. Real user monitoring instead watches your actual visitors' browsers, which means it needs real traffic to say anything at all, and it cannot tell you what will happen tomorrow, only what already happened today.
HostTracker is a synthetic monitoring service - it does not offer real user monitoring, and this page will not pretend otherwise. What synthetic monitoring buys instead: a staging site with zero visitors still gets checked; a break at three in the morning is caught the same as one at rush hour; and because the scenario is deterministic, the result names the exact step or rule that failed rather than a vague symptom. For the full side-by-side comparison, see synthetic vs real user monitoring; the transaction monitoring page also carries a detailed table if you want the mechanics.
Each check type has its own interval floor, because each one costs a different amount of work to run. An HTTP request is cheap and can run as fast as once a minute on a paid plan. An API call adds parsing and rule evaluation but still runs from one minute up to 24 hours. A transaction check opens a real browser and walks a scenario end to end, which is why it has a 10-minute floor - browser checks are expensive to run and to receive, and pairing one with a fast HTTP check on the same site covers both the "is it reachable right now" and the "does the flow still work" questions without running a browser every sixty seconds.
All three let you choose which of the 300+ checkpoints in 158 cities a given monitor runs from - geography matters more than it looks, since a CDN or a geo-routed load balancer can be healthy in one region and failing in another.
The temptation with any new check type is to wire it straight to a page that wakes someone up. Resist it for the first week: let a new monitor run quietly, read a handful of real results, and only then decide who gets paged immediately versus who gets a daily digest. A transaction check that fails because a marketing banner's selector changed is not the same severity as one that fails because checkout stopped completing - write your content assertions on stable, meaningful text so the alert you do get is one worth acting on.
Alerts go out through the channels you configure per contact - email, SMS, voice call, Slack, Telegram, webhook and more - the same set across all three check types, so a transaction failure and an HTTP failure reach the same person the same way. A state change is only confirmed once other checkpoints agree, so the alert you get is already a considered one rather than a single flaky observation; a recovery notice follows once the check passes again, closing the loop without you having to go and check.
Synthetic monitoring is monitoring where the traffic is generated on purpose, on a schedule, by a service outside your own systems, rather than waiting for a real visitor to run into a problem and hoping they tell you. HostTracker's synthetic monitoring comes in three shapes: a scripted browser journey that walks a multi-step flow, an API call judged against rules you write, and a plain HTTP request checked on status, body and timing. All three run from 300+ locations, use the same alert channels, and hold an alert until other checkpoints confirm the failure.
No. HostTracker generates the traffic itself, from its own checkpoints, on a schedule you set - it does not collect timing or error data from your real visitors' browsers. If you need to know what your actual visitors experienced, that is real user monitoring, a different discipline with a different name; see synthetic vs real user monitoring for the full comparison. Synthetic monitoring's advantage is the opposite one: it works before you have a single visitor, and it keeps checking at three in the morning when nobody is browsing.
Uptime monitoring, in the narrow everyday sense, usually means exactly one of these three shapes: the plain HTTP check that requests a URL and looks at the status code and response time. Synthetic monitoring is the broader term that also covers browser monitoring - the scripted journey - and synthetic API monitoring, the call judged by rules. An HTTP check answers "is the server there"; a transaction check answers "does the multi-step flow actually complete"; synthetic API monitoring answers "does the response actually match its contract". A site can pass every HTTP check while its checkout is broken, which is exactly the gap the other two close.
No. All three check types are built in the web editor. A transaction scenario is a list of actions - navigate, click, type and so on - chosen from a menu, with a CSS selector typed into a field. An API monitor's assertion rules are one line of plain, readable syntax each, not a script. An HTTP monitor's keywords and options are form fields. Nothing here is a programming language, though the full action and rule surface is also reachable through the API if you want to automate the setup itself.
Up to ten authored steps, inside a 40-second budget for the whole run. An opening navigation to the monitor's own URL is added automatically as step zero, so the ten steps you write are ten steps of real work - clicks, typed input, content assertions - not nine plus a page load. A flow that genuinely needs more than ten steps is usually better split into two monitors; that also tells you which half broke.
Start with an HTTP check on the site itself - it is the cheapest signal and the always-on baseline every account should have. Then add whichever of the other two matches your highest-value risk: a transaction check if a broken checkout or login flow costs you money directly, an API check if another system - your own app, a partner's integration - depends on an endpoint answering correctly. Most accounts that use all three run the HTTP check most often, the API check next, and the transaction check on the longest interval, since it is the most work to run.
It depends on the check type, because each one costs a different amount of work to run. HTTP checks can run as fast as once a minute on a paid plan. API checks run from one minute up to 24 hours. Transaction checks - because each run opens a real browser and walks a scenario end to end - have a 10-minute floor. A common pattern pairs a one-minute HTTP check for fast outage detection with a transaction or API check every 10 to 15 minutes for the deeper question.
The failure is not trusted on the first observation. HostTracker re-runs the check from other, independent checkpoints, and only confirms the state change once enough of them agree, so one flaky network path or one slow node does not turn into an alert on its own. Once confirmed, HostTracker alerts the contacts you configured through the channels you chose - email, SMS, voice call, Slack, Telegram, webhook and more - after whatever delay each contact was given, and a recovery notice follows once the check passes again.
Start a free trial and add a transaction, API or HTTP check to the same account - the same 300+ locations and the same alerts behind all three.
Part of HostTracker's website monitoring software.
