# Synthetic Transaction Monitoring: Watching User Journeys > Synthetic transaction monitoring scripts multi-step user journeys like login and checkout, then runs them on a schedule to catch broken flows early. Source: https://loadster.com/guides/synthetic-transaction-monitoring/ ## What is Synthetic Transaction Monitoring? **Synthetic transaction monitoring** is the practice of scripting a complete user journey through your web application and running it on a schedule to verify that it still works. A transaction monitor might log in, search for a product, add it to a cart, and check out, verifying each step along the way. If any step fails or takes too long, the monitor alerts your team. It's a specific kind of [synthetic monitoring](https://loadster.com/guides/synthetic-monitoring/), sometimes called web transaction monitoring, user journey monitoring, or end-to-end (E2E) monitoring. Whatever the name, the idea is to test what users actually do rather than just whether the server responds. The word "transaction" here means a sequence of user actions, not a financial transaction (even though checkout is one of the most popular flows to monitor). If you're looking for a hosted way to run these monitors, Loadster's [synthetic monitoring](https://loadster.com/synthetic-monitoring/) platform supports them with real browsers, HTTP-level scripts, or Playwright. ## Why Uptime Checks Aren't Enough for Web Applications A basic uptime check requests a URL and looks for a 200 response. That's useful for catching a complete outage, and not much else. Many real production failures leave the homepage perfectly healthy. A few fairly common examples: - A deploy breaks the login form's JavaScript, so the button does nothing. - The payment provider's API starts timing out, so checkout hangs at the last step. - A search index falls out of sync, and every search returns zero results. - An expired API key in a backend service makes the account page throw an error. - A third-party script blocks rendering on the cart page. In each case, an uptime monitor keeps reporting green while users can't complete the thing they came to do. A synthetic transaction monitor that walks through the flow catches every one of these, because it fails at the broken step. ## Choosing Which User Journeys to Monitor Transaction monitors take more effort to build and maintain than uptime checks, so pick them deliberately. Start with the journeys where a failure hurts most: - **Signup and onboarding.** If new users can't create an account, growth stops quietly. - **Login.** Authentication touches sessions, databases, and often an external identity provider. - **Checkout and payment.** Usually the highest-value flow, and it often depends on several third parties. - **Search.** For catalogs and content sites, broken search is nearly as bad as being down. - **Your product's core action.** Creating a document, booking a room, submitting a form, running a report. One reliable transaction monitor for your most important flow is a better starting point than several fragile ones. Add more once the first one has proven itself quiet and trustworthy. Supporting checks still matter. Keep simple uptime checks on key pages and [API monitoring](https://loadster.com/guides/api-monitoring/) on core endpoints, since they're cheap to run frequently and help you narrow down where a failing transaction broke. ## Browser-Based vs HTTP-Level Synthetic Transaction Monitoring There are two broad ways to script a synthetic web transaction monitor. **Browser-based monitors** drive a real web browser (usually headless Chrome) through the journey: navigate to a page, click a button, type into a field, wait for an element. The browser executes your JavaScript, loads third-party scripts, and renders the page the way a user's browser would. For modern single-page applications, this is usually the most realistic option and also the easiest to script, since you describe what a user does rather than which requests the page makes. **HTTP-level monitors** send the underlying requests directly, without a browser. They're lighter and cheaper to run, and they work well for server-rendered sites and API-driven flows. The tradeoff is that you have to handle what the browser would normally do for you: capturing session tokens and CSRF values from one response and sending them with the next request. Many teams use both. Browser-based monitors cover the user-facing journeys, while HTTP-level monitors cover API sequences and backend flows where a browser adds nothing. ## Scripting Reliable Transaction Monitors A transaction monitor that cries wolf gets muted, and a muted monitor is worse than none. A few habits help keep them trustworthy. **Verify each step, not just the end.** Check that each page shows what it should, like the account name after login or the item in the cart. A failure at step three is far easier to debug than "the script failed somewhere." **Wait for conditions, not fixed delays.** Wait for an element to appear or a request to finish rather than sleeping for a set number of seconds. Fixed delays are slow when the site is fast and flaky when it's slow. **Use stable selectors.** Prefer IDs, test attributes, or accessible labels over brittle CSS paths that change with every redesign. **Use dedicated test accounts and data.** Create monitoring accounts that won't trip fraud checks, skew analytics, or email real customers. For checkout flows, use a test payment method or stop just before the final purchase if your payment provider can't support test transactions in production. **Clean up after yourself.** If the monitor creates records (orders, comments, uploads), make sure something deletes or ignores them, so a year of five-minute monitoring doesn't leave a hundred thousand test orders behind. **Set realistic thresholds.** Base response time thresholds on what the flow normally does, with some headroom, so a normal variation doesn't page someone at night. ## Alerting on Synthetic Transaction Failures Transaction monitors are more complex than uptime checks, so they're more likely to hit an occasional transient failure. A fairly common approach is to require two consecutive failures before opening an incident for heavier browser-based monitors, while alerting on the first failure for simple uptime checks. Good transaction alerts include enough detail to start debugging right away: which step failed, the error or validation that tripped, response times, and ideally a screenshot of what the browser saw. Without that context, the first ten minutes of every incident go toward reproducing the problem. Route alerts to a place your team actually watches, and escalate if nobody responds. Email might be fine for a staging environment; a production checkout flow probably deserves Slack, PagerDuty, or a phone call. ## Synthetic Transaction Monitoring Tools Synthetic transaction monitoring tools mostly fall into three groups. Observability suites include browser-based synthetic checks alongside APM, logs, and RUM. Uptime services sometimes offer transaction checks as an add-on to their simpler pingers. And some platforms combine monitoring with load testing so the same scripts can do both. When comparing tools, look at how scripts are created (recorder, no-code editor, or code), whether real browser checks are supported, whether your team's existing Playwright tests can run as monitors, how many locations are available, how failures are diagnosed, and how the pricing scales as you add more flows or run them more often. ## Synthetic Transaction Monitoring with Loadster Loadster monitors can run three kinds of scripts. Browser Bots drive real Chrome browsers through high-level steps like navigate, click, type, and wait for an element, and you can record them with the free browser extension and refine them in the web-based editor. Playwright Test scripts run as monitors too, so end-to-end tests your team already maintains can run on a schedule. Protocol Bots handle HTTP-level transactions, with [validation rules](https://loadster.com/manual/protocol-scripts/validation-rules/) to verify each response and [capturing rules](https://loadster.com/manual/protocol-scripts/capturing-rules/) to carry tokens from one step to the next. Each monitor cycle keeps a full trace, and browser-based cycles include screenshots of what the bot saw at each step. You can set performance thresholds on response time and cycle duration, choose how many consecutive failures open an incident, and alert by email, SMS, phone call, Slack, PagerDuty, Opsgenie, or webhooks. See [Site & API Monitoring](https://loadster.com/manual/monitoring/) in the manual for the details. Because Loadster is also a load testing platform, a transaction script that monitors checkout every ten minutes can also run with thousands of bots in a [load test](https://loadster.com/load-testing/) before a big launch. To get started, visit [Synthetic Monitoring](https://loadster.com/synthetic-monitoring/), or read the broader [synthetic monitoring guide](https://loadster.com/guides/synthetic-monitoring/) first. A free account comes with 50 units of Loadster Fuel, enough to try a few monitors with no credit card required. ## Frequently Asked Questions ### What is synthetic transaction monitoring? Synthetic transaction monitoring runs a scripted, multi-step user journey against your web application on a schedule, such as logging in, searching, adding an item to a cart, and checking out. Each step is verified, and if any step fails or gets too slow, the monitor alerts your team before real users report the problem. ### How is transaction monitoring different from uptime monitoring? Uptime monitoring checks whether a URL responds, usually by looking for a 200 status code. Synthetic transaction monitoring goes through a complete flow and verifies each step, so it catches the fairly common case where the site is up but something important, like login or checkout, is broken. ### Which user journeys should I monitor? Start with the flows that cost you the most when they break: signup, login, checkout or payment, and whatever core action your product exists for. One well-built transaction monitor for your most important flow is worth more than a dozen fragile ones. ### Should transaction monitors use real browsers or HTTP requests? Real browser monitors are usually easier to script and more realistic for JavaScript-heavy web applications, since the browser handles rendering, client-side logic, and third-party scripts. HTTP-level monitors are lighter and work well for server-rendered sites and API sequences. Many teams use browsers for user-facing journeys and HTTP-level checks for APIs. ### How often should synthetic transaction monitors run? Every five to fifteen minutes is a fairly common cadence for browser-based transaction monitors, with lighter uptime checks running every minute or two. Critical revenue flows sometimes run more often. Faster schedules catch problems sooner but cost more and can create more noise. --- **Next Steps:** Ready to monitor your most important user journey? Set up a transaction monitor with [Synthetic Monitoring](https://loadster.com/synthetic-monitoring/) using a Browser Bot, Protocol Bot, or Playwright script. #### Related Guides * [Synthetic Monitoring: Tools and Techniques](https://loadster.com/guides/synthetic-monitoring/) — the full primer on how synthetic monitoring works. * [Synthetic Monitoring vs Real User Monitoring (RUM)](https://loadster.com/guides/synthetic-monitoring-vs-real-user-monitoring/) — active and passive monitoring, and why most teams use both. * [API Monitoring](https://loadster.com/guides/api-monitoring/) — synthetic checks for API uptime, response time, and correctness. * [Website Load Testing](https://loadster.com/guides/website-load-testing/) — running the same user journeys with many concurrent bots.