Synthetic Transaction Monitoring (STM): Tools, Use Cases, and Best Practices
Synthetic Transaction Monitoring (STM) is a proactive monitoring approach used to measure the performance, functionality, and user experience of multi-step interactions with a web application or service. Unlike single-request synthetic tests that check a page or API endpoint, STM scripts simulate complete user journeys — logging in, browsing items, adding products to a cart, completing a purchase — so teams can validate that critical paths through an application work end to end before real users encounter problems.
This guide explains how synthetic transaction monitoring works, how it differs from broader synthetic monitoring, what features matter most for network and application teams, and how Kentik approaches STM as part of a network intelligence platform.
Kentik in brief: Kentik is a network intelligence platform with built-in synthetic monitoring capabilities, including synthetic transaction monitoring for multi-step user journeys. Kentik Transaction tests use Puppeteer scripts to simulate complex user interactions from a global network of agents plus customer-deployed private agents — and because they run inside the same platform as flow analytics, BGP routing, and device telemetry, transaction failures can be traced from symptom to network-layer root cause without context-switching across tools.
Learn how AI-powered insights help you predict issues, optimize performance, reduce costs, and enhance security.
Synthetic Transaction Monitoring at a Glance
- What it is: A monitoring discipline that uses scripted, multi-step browser interactions to simulate real user journeys (login → search → checkout, for example) and measure their performance and reliability.
- How it works: Automated scripts running in headless browsers execute predefined sequences of actions from agents in multiple geographic locations, capturing performance and screenshots at each step.
- Why it matters: Critical revenue-driving paths often involve many components — authentication, search, recommendation engines, payment, fulfillment — and a failure in any single step can break the user experience. STM detects these failures before users do.
- How it differs from synthetic monitoring: Synthetic monitoring covers all proactive testing (HTTP, DNS, page load, BGP); STM is a specific subset focused on multi-step transaction flows that simulate user behavior.
- Where it fits in DEM: STM is the proactive, journey-aware component of digital experience monitoring — complementary to Real User Monitoring (passive observation of real users) and broader synthetic monitoring (single-step tests).
What is Synthetic Transaction Monitoring?
Synthetic Transaction Monitoring is the active process of simulating user-driven web transactions on a regular schedule to validate that those transactions complete successfully and within performance targets. A “synthetic transaction” is a scripted sequence of actions a user might take — typically captured as a recorded interaction or written as code — that the monitoring platform replays from automated agents.
Most STM implementations focus on web applications, where the transactions involve a client (such as a web browser) interacting with a server (a web application, backend database, cloud service, or API). The actions captured in a transaction script can include:
- Loading a page
- Filling and submitting a form (e.g., login credentials)
- Clicking on links or buttons
- Selecting items from a list or dropdown
- Adding items to a cart
- Navigating through multi-page flows (checkout, sign-up, account configuration)
- Verifying that expected content or confirmations appear
The result is a continuous, controlled measurement of whether a critical path through the application is working — independently of whether real users happen to be active at the moment.
Synthetic Monitoring vs. Synthetic Transaction Monitoring
The terms “synthetic monitoring” and “synthetic transaction monitoring” are often used interchangeably, but they describe different scopes of testing.
Synthetic monitoring is the broader category. It includes any active, scripted testing of network-accessible resources — covering all layers of the stack from network to routing to application. A synthetic test can be as simple as a ping or a single HTTP GET, or as complex as a full multi-step transaction.
Synthetic Transaction Monitoring specifically refers to monitoring web transactions — the multi-step interactions between a client and a remote server, cloud service, or API — performed in response to specific user behaviors. STM is a subset of synthetic monitoring, focused on the transaction layer.
For example, a basic synthetic page load test might generate traffic to a site and evaluate the load performance of each element on a single page. The load order and load duration of each element in the Document Object Model (DOM) can be presented in a waterfall graph:
A page load test like this answers “is the page loading correctly and quickly?” but not “can a user actually log in, search, add an item to their cart, and complete a purchase?” That deeper question is what synthetic transaction monitoring addresses — and on an e-commerce site, with dozens of internal and third-party components contributing to a successful purchase, that’s the question that actually predicts revenue impact.
Why Synthetic Transaction Monitoring matters
Most synthetic monitoring is about proactively testing the network, the services it relies on, and the applications it delivers — using artificial traffic instead of waiting for users to encounter problems. STM extends that proactive philosophy into the transaction layer of the application stack itself.
Consider a typical e-commerce site hosted in multiple public cloud regions, accessed by customers worldwide who log in, search for products, make purchases, leave reviews, or contact support. If any of these journeys is unavailable, malfunctioning, or slow, the consequences are immediate: lost confidence, lost conversions, lost revenue. Single-page or single-API checks won ’t catch a broken multi-step flow — only a transaction test that walks the full journey will.
STM lets teams continuously validate the user-level interactions that matter most to the business — not just whether individual components are healthy, but whether they work together. Every step of a critical user journey can be simulated and measured, giving teams the ability to detect and address problems before they generate support tickets or revenue impact.
Common STM use cases
STM use cases generally fall into two categories:
-
Testing the responsiveness of journeys in applications you own from various geographic regions. A typical example is simulating customer behavior on an e-commerce site from the geographies where your customers actually live, ensuring performance is consistent across regions.
-
Testing from your locations to commonly used external apps. A multi-location organization might monitor response times for SaaS apps like Microsoft 365, Salesforce, or Zoom from each of its offices, measuring the experience employees actually get rather than relying on the SaaS provider’s status page.
Both categories share the same goal: detect transaction-level degradation before it becomes a user-reported problem.
What features matter in Synthetic Transaction Monitoring
Not all STM implementations are equally useful. The features that distinguish a production-grade transaction monitoring capability from a basic one tend to fall into a few categories:
Recording and scripting workflows
Writing transaction scripts by hand is time-consuming and error-prone. The most usable STM platforms let teams record real user interactions in a browser (typically using Chrome DevTools or a similar recorder) and export them as executable scripts — most commonly as Puppeteer scripts, which run in headless Chromium. This dramatically lowers the bar for creating new transaction tests.
Multi-agent execution
Running a transaction from a single location only tells you how that location experiences it. Production STM platforms execute the same transaction script from multiple agents simultaneously — public agents in different geographies, private agents inside corporate networks or cloud VPCs — so teams can compare experience across the locations that matter to their users.
Step-level metrics and screenshots
A transaction either succeeds or fails — but when it fails, the team needs to know which step failed and what the user would have seen. Screenshots captured at each step, alongside per-step timing data, transform a “transaction failed” alert into actionable diagnostic information.
Waterfall analysis of page elements
When a step is slow, the cause is often buried in the page’s component dependencies — a slow third-party script, a delayed API call, a hung CDN asset. Waterfall views that show the load order and duration of every DOM element on every visited page expose these dependencies clearly.
Integration with network telemetry
A transaction failure can originate at the network layer (latency, routing, DNS, TLS), the cloud-provider layer (regional issues, backbone problems), or the application layer (slow database, third-party service degradation). STM is most valuable when transaction results live in the same platform as flow analytics, BGP routing data, and device telemetry — so the next investigation step is always one click away.
Configurable alerting and baselining
Static thresholds quickly become noisy or stale; dynamic baselines catch regressions that absolute thresholds miss. Look for STM platforms that offer both — and that integrate with the notification channels teams actually use (PagerDuty, Slack, webhooks, ServiceNow).
Synthetic Transaction Monitoring with Kentik
Kentik’s Synthetic Transaction Monitoring features support all of these capabilities within the broader Kentik network intelligence platform:
- Browser-based recording. Capture a transaction by running it in a regular Chrome browser using Chrome DevTools, then export as a Puppeteer script.
- Puppeteer script import. Import the recorded (or hand-written) Puppeteer script into a Kentik Transaction test.
- Multi-agent execution. Run the script from any number of public global agents or private ksynth-agents — including agents in your own data centers, branch offices, or cloud VPCs.
- Total transaction time alerting. Set thresholds on overall transaction completion time and alert through standard notification channels.
- Screenshots at every step. Each transaction execution captures screenshots at the actions specified in the script, providing visual evidence of what the user would have seen.
- Waterfall analysis. View load order and load duration for every element in the DOM of each page visited, including third-party content and CDN assets.
Here’s what Transaction test setup looks like in Kentik. In this simple example, four geographically distributed agents are configured to visit several URLs and capture metrics and screenshots at each step:
Tests can be set to run on configurable intervals — Transaction tests default to 30-minute intervals, with shorter or longer intervals available. Tests can run from hundreds of Kentik public test agents, and private agents can be deployed in customer infrastructure with a few CLI commands.
Synthetic Transaction Monitoring test results in Kentik
Kentik displays STM results on a timeline:
- Results are shown over a user-selectable time period
- Performance regressions are color-coded (orange for warning, red for critical) against static or dynamic baselines
- Selecting a point on the line shows total completion time and the rolling standard deviation baseline
- Screenshots captured during the transaction are inline with the timeline
- The Waterfall tab shows the load order and load duration of every element in the DOM of every page visited
Why network-aware STM matters
Most STM platforms focus on the application and browser layer — they tell you the transaction failed but don’t connect the failure to network-layer causes. Kentik’s STM lives inside a network intelligence platform, which means transaction degradation can be correlated with:
- Real flow data to see whether actual user traffic is also affected, and how much
- BGP routing context to detect whether a routing change correlates with the regression
- Device and interface metrics to validate that internal network health isn’t contributing
- Synthetic ping and traceroute results along the path to the test target, isolating which hop or AS is contributing to slowdown
This makes Kentik’s STM particularly useful for transaction failures that turn out to have network-layer causes — which, for any application that depends on the internet path between users and cloud providers, is most of them.
Related Kentipedia articles and Kentik solutions
- What is Digital Experience Monitoring (DEM)?
- What is Synthetic Monitoring?
- Synthetic Monitoring vs Real User Monitoring (RUM)
- What is End User Experience Monitoring?
- Network Performance Monitoring
- Kentik Synthetics
- Kentik Global Synthetic Network
- Digital Experience Monitoring Solutions
FAQs about Synthetic Transaction Monitoring
What is synthetic transaction monitoring?
Synthetic transaction monitoring (STM) is the active process of using scripted, multi-step browser interactions to simulate real user journeys — like logging in, searching, adding to a cart, and checking out — and measuring their performance and reliability. Tests run continuously from automated agents in multiple geographic locations, validating that critical paths through an application work end to end before real users encounter problems.
What’s the difference between synthetic monitoring and synthetic transaction monitoring?
Synthetic monitoring is the broader category — any active, scripted testing of network-accessible resources, including pings, traceroutes, DNS lookups, HTTP requests, page loads, and BGP monitoring. Synthetic transaction monitoring is a specific subset focused on multi-step transactions that simulate user behavior in a web application. STM tests are typically scripted in tools like Puppeteer and run in headless browsers to replicate the experience a real user would have.
How does synthetic transaction monitoring work?
STM works by using “agents” distributed at different locations to periodically run proactive scripted tests against a target application. Each agent runs a script (commonly a Puppeteer script) that simulates user interactions like logging in, clicking objects, and submitting forms — capturing performance metrics, completion times, and screenshots at each step. Results are aggregated for analysis, baselining, and alerting.
What are synthetic transactions?
Synthetic transactions are simulated, scripted web interactions — typically a sequence of HTTP requests and browser actions — that represent the multi-step communication between a client (a browser) and one or more servers (web servers, APIs, databases, cloud services). They’re called “synthetic” because they’re generated by automated tooling rather than real users, but they exercise the same code paths and infrastructure that real users would.
How do I alert on degradation of critical user journeys from key sites?
User-journey alerting requires scripted multi-step tests (login → action → confirmation, for example) running from agents located in the geographies and networks where critical users live, with health thresholds tuned per step rather than only on overall test outcome. Kentik supports this with Puppeteer-based Transaction tests that record and replay user journeys from any agent location, plus configurable per-metric health thresholds (latency, jitter, loss, completion time) that integrate with notification channels like PagerDuty, Slack, and webhooks.
How can I simulate user journeys over different network paths?
Simulating user journeys across different network paths means running the same scripted journey from agents in different geographies, on different ISPs, or behind different cloud regions — then comparing results. Differences in completion time, error rates, or step-level performance reveal which paths or providers are degrading the user experience. Kentik supports this by letting Transaction tests run from any number of public or private agents simultaneously, with results displayed side by side so path-related differences are immediately visible.
What features are critical in synthetic transaction monitoring for networks?
For network teams, the most useful STM features go beyond browser-level scripting: path visibility (so transaction degradation can be traced to specific hops or AS paths), correlation with flow data (so traffic patterns can confirm whether real users are affected), integration with BGP routing context (so internet-path changes can be correlated with transaction regressions), and screenshots plus waterfall views (so failure causes can be diagnosed visually). Kentik supports this with Puppeteer-based Transaction tests integrated into the same platform as flow analytics, BGP monitoring, and path-aware traceroute data.
What’s the best method to measure page load performance due to network?
Network-attributable page load performance comes from a few specific metrics: DNS resolution time and TLS handshake time (both depend on network and provider behavior rather than application code), plus traceroute-based path analysis to identify which hops contribute to slowdowns. For full transaction journeys, those network-layer metrics combine with per-step browser timings and waterfall analysis to isolate whether slowdowns are network-side or application-side. Kentik supports this with Page Load and Transaction tests that capture DNS, TLS, navigation, connect, and response timings as separate metrics, plus path views showing the AS-level routing path each test took.
How long should synthetic transaction tests run, and how often?
Test interval depends on test complexity and the criticality of the journey being monitored. Single-step HTTP or DNS tests can run as often as every minute; full transaction tests typically run on longer intervals because each execution takes longer and consumes more resources. In Kentik, Transaction tests default to 30-minute intervals — enough to detect meaningful regressions on most critical journeys without overwhelming the target application, with shorter or longer intervals available for higher- or lower-priority tests.
Can synthetic transaction monitoring catch issues that single-page tests miss?
Yes — and this is the core reason STM exists. Single-page tests confirm that a page loads, but they can’t catch failures that emerge only across multi-step journeys: a session that doesn’t persist across page transitions, a cart that drops items between adds, a payment processor that times out only on certain payment types, a search index that returns stale results after a recent update. These multi-step failures are common in production, and only transaction-level testing reveals them.
How does synthetic transaction monitoring fit into a digital experience monitoring strategy?
STM is one of the proactive components of digital experience monitoring (DEM). It complements broader synthetic monitoring (single-step tests like ping, DNS, and HTTP) and Real User Monitoring (passive observation of actual users). Together, these methods cover different layers of the user experience: synthetic catches issues before users encounter them, RUM captures real-world experience as users have it, and STM specifically validates that the multi-step journeys that drive business outcomes are working as expected.
What kinds of applications benefit most from synthetic transaction monitoring?
STM is particularly valuable for applications where multi-step user journeys drive business outcomes: e-commerce sites (browse → cart → checkout), SaaS platforms (login → dashboard → action → save), B2B portals where partners log in and complete workflows, and any application with revenue-driving conversion paths. STM is also useful for monitoring SaaS applications your organization depends on — testing whether employees can actually log in, send a message in Slack, or join a Zoom meeting from each of your office locations.
Monitor user journeys with Kentik Synthetics
Kentik combines synthetic transaction monitoring with the broader network intelligence platform — so when a critical user journey degrades, you can move from “the test failed” to “here’s what changed in the network” in a single workflow.
- Get a demo — See Kentik Synthetic Transaction Monitoring in action
- Kentik Synthetics — Continuous testing with ping, traceroute, HTTP, DNS, page load, and Puppeteer-based transaction tests
- Kentik Global Synthetic Network — Hundreds of public agents plus customer-deployed private agents
- Digital Experience Monitoring Solutions — DEM powered by unified synthetic and real traffic data
- Debug faster: web and network performance webinar — On-demand webinar on web transaction testing
