Synthetic transaction monitoring
HostTracker's web transaction monitoring replays a real user journey - log in, search, add to cart, check out - in a real browser from 300+ locations, and alerts you the moment a step breaks.
How a transaction check runs, from the first step to the alert
Every run, from the first navigation to the verdict.
No macro recorder to go stale. Name the steps - the name is what the alert says.
checkout · 5 steps · 3.6 s
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
navigate, click, type, select, checkContent, hover, waitForNavigation, sleep, screenshot and back - each with its own timeout and name.
Any browser console error fails the check, with an allow-list of up to ten substrings for a noisy third-party script.
Create and edit transaction monitors over REST, the SDKs, Terraform or MCP - the full action set included.
Learn moreStart with the one journey whose failure costs you money, get it green, and only then add the rest. A monitored flow you trust beats five you half-configured.
Open a product page, click add to cart, assert the cart badge shows one item, open checkout, assert the total and the payment form rendered. Stop one step before the order is placed and you get full coverage with no test orders in your database.
Type a dedicated test account's credentials, submit, wait for the navigation, then assert on text that only exists once the session is real. This is the single highest-value scenario for most applications - a broken login is a total outage that returns 200 on every page.
Fill the fields, submit, assert on the thank-you wording. Silent form breakage is the classic invisible outage: nothing errors, nothing alerts, and the enquiries simply stop arriving until somebody notices weeks later.
Type a query that must always match something, submit, then assert both that a known result is present and that the empty-state wording is absent. That second assertion is what catches a search index that quietly stopped rebuilding.
Walk the registration form to the final confirmation screen and assert on it, pointing the form at a test target so monitoring never creates real accounts. Signup breaks quietly and expensively - nobody complains about a signup they could not complete.
Request a reset and assert the confirmation screen appears. It depends on your mail pipeline, your queue and your token service, so it is an unusually good canary for backend problems that the front page never shows.
HostTracker's transaction check service ensures that all stages of an online transaction process are functioning correctly. It tests each step of the process, from adding items to a cart to completing a purchase. This helps find and fix problems that could stop customers from buying, which improves the customer experience and reduces lost sales.
HostTracker's transaction check feature is comprehensive and covers various aspects of an e-commerce transaction. It includes things like form submissions, button clicks and page redirections, to copy how real users behave. This tests the whole purchasing process to make sure it works well. It also provides detailed logs and reports to help administrators quickly find and fix any issues, without affecting the user's purchasing journey.
Transaction checks make e-commerce websites more reliable and efficient. It helps keep transactions running smoothly by fixing problems before they happen. This means customers are more satisfied and trust the site more. It also helps to keep customers happy by avoiding lost sales. This makes it a useful tool for online shops.
The step by name, its screenshot, and the timing of every step before it.
The result and the alert carry the step's name, so "down" becomes "3 - submit login stopped redirecting".
Captured when a step fails, next to the one after the final step - what the page looked like on the way in.
Websites, servers, APIs, certificates. One check type per page, the same locations, alerts and reports behind all of them.
"I've worked with this monitoring service for a long time, and my daily routine is no longer a problem. It quietly watches all my sites and lets me respond the moment something goes wrong."
Trusted by teams at
Every chapter opens in place, so the page stays short.
Synthetic monitoring means the traffic is generated on purpose: instead of waiting for a visitor to hit a problem and hoping they tell you, a monitoring service drives your site itself, on a schedule, from outside your network. Transaction monitoring is the multi-step form of it. A simple synthetic check requests one URL and looks at the answer. A transaction check opens a real browser, walks an ordered scenario - open the page, log in, search, add to cart, check out - and asserts on what it finds at each stop.
The difference matters because most of what customers actually do on a website is a sequence, not a page view. Every individual page in a checkout can return HTTP 200 while the checkout itself is broken: a button removed by a deploy, a form posting to an endpoint that now 404s, a JavaScript error that stops the wizard on step three. Nothing about those failures shows up in a status code, so nothing about them shows up in ordinary uptime monitoring.
Not the same thing as financial transaction monitoring. In banking and compliance, "transaction monitoring" means screening payments for fraud and money laundering. This page is about the web-operations meaning: automatically replaying a user journey on your own website to prove it still works. HostTracker is a website monitoring service - it watches your checkout flow, not your payment ledger.
A fast HTTP check is the right tool for "is the site up". It is a single request, so its verdict is a single response: the status code, the response time, and whatever keyword or assertion rule you set on the body it received. That is a lot of coverage for very little cost - and it stops precisely where the first response ends. Everything below the line in this table happens after that point.
| What actually broke | Fast HTTP check | Transaction check |
|---|---|---|
| Server unreachable, DNS failure, TLS handshake refused | Caught | Caught |
| The landing page returns 500 after a deploy | Caught | Caught |
| The page loads, but the "Add to cart" button was removed by a release | Missed - the HTML still returns 200 | Caught - the click step cannot resolve its selector |
| The login form posts to an endpoint that now 404s | Missed - the form's own page is fine | Caught - the step after the submit never reaches the account page |
| A JavaScript exception stops the checkout wizard on step two | Missed - JavaScript never runs | Caught - the browser runs the script, and the check can fail on console errors |
| The payment page renders an error banner instead of the confirmation | Missed - a rendered error is still a 200 | Caught - a content assertion on the confirmation text fails |
| The session cookie stops being set, so step three bounces back to the login page | Missed - there is no session to lose | Caught - one browser session runs the whole scenario |
| A third-party script - chat widget, tag manager, payment SDK - blocks rendering | Missed - third-party assets are never fetched | Caught - the browser fetches them like a visitor does |
| The flow works but each step now takes eight seconds | Partly - only the first response is timed | Caught - each step is timed, and a step can time out |
Neither check replaces the other. The honest recommendation is to run both: a one-minute HTTP check on the same site for fast outage detection, and a transaction check on the one or two journeys that actually produce revenue. If you want the availability half first, start with distributed availability monitoring from 300+ checkpoints and add the flow on top.
Each run starts a real, headless Chromium browser on one of HostTracker's checkpoints and gives it one browser session for the whole scenario. That single detail is what makes the check meaningful: cookies, tokens and login state set in step two are still there in step five, exactly as they would be for a person clicking through your site. JavaScript executes, redirects are followed - including the ones your own scripts trigger - and third-party assets load the way a visitor's browser loads them.
The scenario is sequential and fail-fast. Steps run in the order you wrote them, and the first step that fails ends the run and becomes the reported cause. You never get a wall of downstream errors caused by one broken button - you get the broken button.
Two optional switches change how strict a run is. Fail on console error turns any browser console error into a failed check - powerful on a well-behaved application, and paired with an allow-list of up to ten substrings so a known-noisy third-party script does not cry wolf. Skip loading media files is on by default; turn it off when the thing you are testing is the media itself.
A transaction is a list of steps, and each step is one action against the page. There is no macro recorder to go stale - you build the scenario explicitly, which is also why it keeps working when your marketing team changes the copy on a button.
| Action | What the step does |
|---|---|
| navigate | Open a URL. The first navigation - to the monitor's own address - is added for you as step zero. |
| click | Click an element resolved by CSS selector, or a viewport coordinate. Left, right or middle button, with an optional hold delay. |
| type | Type text into a field, optionally with a delay between keystrokes so the page's own input handlers keep up. |
| select | Assert on a selector's cardinality: it must match nothing, exactly one element, at least one, or any number. Acts on all matches, the first, or a random one. |
| checkContent | Assert on the rendered text. Up to ten keywords, any or all of them, case-sensitive or not, present or deliberately absent, and optionally only in the visible text. |
| hover | Hover an element - the way you reach a menu or tooltip that only exists on mouse-over. |
| waitForNavigation | Wait for the page to navigate, optionally failing the step when no navigation happens in time. |
| sleep | Pause, from 1 millisecond up to 10 seconds, with optional random jitter so a scenario does not hammer the same instant every run. |
| screenshot | Capture the page mid-flow, so a failure two steps later still shows you what the page looked like on the way in. |
| back | Go back one entry in the browser history. |
Any step can carry a screenshot and a wait-for-navigation afterwards, its own timeout override, and a short name of up to 19 characters. Name your steps - the name is what appears in the result and in the alert, so "3 - submit login" is the difference between a page that is "down" and a page whose login POST stopped redirecting. In the web editor, screenshots and navigation waits are offered as after-step behaviours; the full action set including hover is available through the API.
id or a data- attribute you control, not a generated class name that
changes with the next build.checkContent step after each meaningful transition is what turns a
sequence of clicks into an actual test: after the login, assert on the account-page text; after
checkout, assert on the confirmation wording.If you want to sanity-check the starting URL before building the scenario, run a free instant HTTP check on it - no login required - or measure how the page loads in a real browser with the free page speed test.
The run stops at the failing step and records what it saw. The result names the step, classifies the failure - a timeout, an element the selector could not resolve, a content assertion that did not match, an HTTP error, a connection error, a browser console error, or a misconfigured step - and keeps the per-step durations, the URL, IP and HTTP status each navigation landed on, the browser's console messages, and a screenshot of the page at the moment it broke.
Then it is double-checked before anyone is woken up. A single failing observation is not treated as an outage: the check is re-run across additional independent checkpoints and the state change is only confirmed when the quorum agrees. The default is a majority verdict across up to seven agents with a minimum of three - so one flaky checkpoint, or one transient network hiccup between a data centre and your host, cannot manufacture an alert on its own.
Once the transition is confirmed, alerting follows the delay each contact chose: immediately, or only after 3, 5, 15, 30 or 60 minutes, or 3, 6, 12 or 24 hours of continuous failure. Alerts go out over the nine notification channels HostTracker supports - email, SMS, voice call, webhook, Slack, web push and the messenger apps Telegram, Discord and Viber - and a recovery notice follows when the flow starts completing again.
A transaction check is the most powerful monitor HostTracker offers and the one with the most real-world constraints. Knowing them up front saves an afternoon.
The two approaches answer different questions, and a team that understands the split stops expecting one to do the other's job. HostTracker is a synthetic website monitoring service: it generates the traffic itself, from its own checkpoints, on a schedule you control.
| Synthetic transaction monitoring | Real-user monitoring | |
|---|---|---|
| Who generates the traffic | The monitoring service, on a fixed schedule | Your actual visitors, whenever they happen to arrive |
| Works before you have traffic | Yes - a staging site with no users still gets checked | No - no visitors, no data |
| Notices a break at 3 in the morning | Yes - the schedule does not sleep | Not until somebody shows up |
| Names the exact step that failed | Yes - the scenario is deterministic | Rarely - you see the symptom, not the sequence |
| Reflects what real customers experienced | No - it is a controlled sample | Yes - that is the whole point |
| Requires code on your site | No - it runs entirely from outside | A script or SDK in every page |
| Covers a flow customers rarely complete | Yes - you choose what gets exercised | No - rare paths stay unmeasured |
If what you want next is the timing half rather than the flow half, HostTracker measures real browser page loads too - see browser access and page-load timing - and for the machine-to-machine equivalent of a transaction, an API monitoring check validates the response contract rather than the rendered page. Server-side, a database query monitor often explains why a flow got slow in the first place.
Transaction monitoring for a website is a check that automates a real multi-step user flow - like filling out a form, logging in, adding an item to a cart, or completing a purchase - and verifies that each step completes correctly and the whole sequence produces the expected outcome. Unlike a simple check that only confirms a single page loads, transaction monitoring follows the same path a real visitor would take, submitting data and clicking through pages in sequence, then validates the result against rules you define. This matters because a website can appear perfectly healthy by every simple availability measure - the homepage loads, individual pages return 200 status codes - while a critical multi-step process like checkout is silently broken partway through. HostTracker's transaction monitoring is built specifically to catch that category of failure.
HostTracker's transaction monitoring can automate and validate a range of website interactions, including form submissions, button clicks, and page-to-page redirections that together model how a real user moves through your site. This covers common scenarios like completing a signup or login flow, submitting a contact or lead-generation form, and multi-step purchasing processes such as adding items to a cart and proceeding through checkout. Because the check simulates real user behavior step by step rather than just loading a single page, it can validate that each stage of the process actually works and produces the expected result, not just that the pages involved happen to load. This makes it useful for any website where a broken interactive flow - not just a broken page - would cost you leads, signups, or sales.
Basic uptime monitoring checks whether a single page or endpoint responds and returns a normal status code, which tells you the server is reachable but says nothing about whether a multi-step process built on top of it actually works. Transaction monitoring goes further by automating an entire sequence of steps - submitting a form, clicking through pages, completing a purchase flow - and validating that each step succeeds and the end-to-end process produces the correct outcome. A website can pass every uptime check while its checkout process is completely broken at the payment step, because each individual page still loads fine in isolation; only a check that actually walks through the transaction would catch that. For any site where conversions depend on a multi-step flow, transaction monitoring covers a category of failure basic uptime checks simply cannot see.
Yes, this is one of the primary use cases for transaction monitoring. HostTracker's transaction checks walk through a defined sequence of steps - such as adding an item to a cart, proceeding to checkout, filling in required fields, and reaching a confirmation page - and validate that each step completes as expected along the way. This means a failure introduced anywhere in the flow, whether it's a broken "add to cart" button, a form validation bug, or a checkout page that fails to load after a recent deployment, gets detected and reported with detailed logs pointing at the specific step that failed. Catching this kind of issue quickly matters because a broken checkout step directly costs sales, and it can go unnoticed by simple uptime checks for a long time since the individual pages involved may still return normal status codes.
When a step in a transaction check fails - a form doesn't submit, an expected page doesn't load, or a validation rule isn't met - HostTracker records the point of failure and sends an alert through your configured notification channels, so you know not just that something broke, but where in the flow it happened. Detailed logs and reports accompany the alert, giving administrators the specific step and outcome needed to investigate quickly rather than having to manually retrace the entire flow themselves. This step-level detail is what makes transaction monitoring practically useful for fixing problems fast: knowing that "checkout is broken" is far less actionable than knowing the failure happens specifically at the payment confirmation step after a particular recent change, which narrows down the likely cause considerably.
No, while multi-step purchase flows are a common example, transaction monitoring is useful for any website where a sequence of user actions - not just a single page load - needs to work correctly. This includes login and signup flows for SaaS applications, lead-generation and contact forms for service businesses, multi-page application processes, and any site traversal where a broken link or a failed form submission partway through would stop a visitor from completing what they came to do. Any interactive process where losing a user midway through has a real cost - a missed signup, an abandoned lead form, an incomplete application - benefits from having that specific flow automated and checked regularly, rather than assuming it still works simply because the individual pages involved load without error.
A transaction check runs on an interval you choose between 10 minutes and 24 hours - 10, 15, 30 and 45 minutes, then 1, 2, 4, 6, 12 and 24 hours. The floor is higher than the one-minute minimum HostTracker offers for simple HTTP checks, and deliberately so: a transaction check starts a real browser, loads the page with its JavaScript, and walks through your scenario step by step, which takes seconds of real work rather than a single request. The usual pattern is to pair the two - a one-minute HTTP or ping check answers "is the site reachable right now", and a transaction check every 10 or 15 minutes answers the harder question of whether the checkout, the login or the signup flow behind it still completes. That combination catches a hard outage within a minute and a broken flow within one check cycle, without running a browser session against your application every sixty seconds.
No, and you should not. A transaction check submits real forms against your real site, so the right setup is a dedicated test account, a test product or SKU, and - if the flow reaches payment - your payment provider's sandbox or test-card mode, exactly as you would for any automated end-to-end test. Many teams stop the monitored scenario one step before the irreversible action: reach the payment page, assert that it rendered with the correct total, and end there. That still proves every step up to the point of sale works, without creating an order every ten minutes. The same rule applies to signup and lead flows - point the scenario at a test form target, or filter the monitor's submissions out on your side, so that monitoring traffic never pollutes your real data.
Start a free trial and monitor your critical user flows - login, search, checkout - around the clock.
Part of HostTracker's website monitoring software.