Network Synthetic Monitoring: How It Works, Test Types, and Path Analysis (2026)
Reviewed for technical accuracy by: Eric Hian-Cheong, Senior Product Marketing Manager at Kentik, who leads go-to-market strategy for Kentik AI, NMS, and flow solutions.
Most monitoring tells you whether a service is up. Network synthetic monitoring tells you what the experience looks like from where your users are — and, when it’s done right, where on the network path a problem actually lives. It’s the proactive half of measuring digital experience across networks you don’t fully control: the public internet, cloud backbones, SaaS platforms, ISPs, and CDNs.
This article explains what network synthetic monitoring is, how it works, the test types network teams rely on, how it differs from web and application synthetic monitoring, and how it connects to network path analysis.
Kentik in brief: Kentik is a network intelligence platform with built-in synthetic monitoring. It runs continuous tests — ping, traceroute, HTTP, DNS, page load, and transaction tests — from a global network of agents plus private agents in your own infrastructure, and it correlates those results with real flow data and BGP routing. That pairing is the point: synthetic tests show that an experience degraded, while flow and routing context show where and why.
Learn how AI-powered insights help you predict issues, optimize performance, reduce costs, and enhance security.
Network synthetic monitoring at a glance
- What it is: Proactive, scripted tests run from distributed agents that simulate user traffic and network probes to measure the performance, availability, and paths of applications, APIs, and networks — before real users are affected.
- How it works: Agents run scheduled tests (from sub-minute to daily), collect metrics like latency, jitter, loss, and response time, and alert when thresholds are breached.
- How it differs from web synthetic monitoring: Web synthetic tools focus on the browser and the application. Network synthetic monitoring adds the internet and network path — routing, DNS, and hop-by-hop behavior between the user and the service.
- Why path analysis matters: A failed test is only actionable if you can see the path it took. Network synthetic monitoring pairs naturally with network path analysis to show the route and where it degraded.
- Key use cases: SaaS reachability across ISPs and regions, VoIP and gaming quality of experience, hybrid and multicloud connectivity, SLA validation, and internet outage detection.
What is network synthetic monitoring?
Network synthetic monitoring is a proactive testing method that uses agents to generate simulated traffic and network probes — pings, traceroutes, DNS lookups, HTTP requests, and multi-step transactions — on a continuous schedule. Because the tests don’t depend on live user traffic, they surface problems before users encounter them, and they keep measuring during off-hours when real traffic is low.
The “network” qualifier matters. General synthetic monitoring often stops at the application: did the page load, did the API return 200. Network synthetic monitoring extends the same proactive approach across the network and internet path — measuring not just whether a service responded, but the latency, loss, routing, and DNS behavior along the way. That makes it the proactive layer of digital experience monitoring for teams whose experience depends on networks they don’t own.
How network synthetic monitoring works
Network synthetic monitoring has four moving parts, and understanding them makes the test types that follow easier to understand:
- First, agents run the tests. Public agents sit in internet hubs and cloud regions around the world for outside-in testing; private agents run inside your own data centers, branches, and VPCs for inside-out and private-to-private testing.
- Second, scheduling and scripting define what runs and how often — from sub-minute network probes to periodic multi-step transactions.
- Third, data collection records the metrics that matter for each test type: round-trip time, jitter, packet loss, DNS resolution time, TLS handshake time, time to last byte, and per-step timings.
- Fourth, alerting compares results against health thresholds and routes notifications to channels like PagerDuty, Slack, and webhooks when performance degrades.
The value multiplies when these results don’t live in isolation. Tied to real network telemetry, a degraded test can be traced from symptom to root cause, without hopping between tools.
Types of synthetic tests in networking
Different layers of digital experiences can fail independently, so production-grade network synthetic monitoring uses several test types, each of which measures a different layer.
- Ping and traceroute tests generate latency, jitter, and packet loss metrics plus hop-by-hop path data — the foundation of network-layer testing.
- DNS tests validate resolution behavior and timing across authoritative and recursive servers.
- HTTP and API tests measure status codes, time to last byte, response size, DNS resolution time, and TLS handshake timing.
- Page load tests use a headless browser to measure end-to-end web performance — navigation, domain lookup, connect, and response timings.
- Transaction tests simulate multi-step user journeys (login, search, purchase) using scripted browser automation.
- BGP monitoring tests track route announcements, withdrawals, and reachability, tying the control plane to the data-plane tests above.
A network intelligence platform can also generate tests automatically. Kentik’s autonomous, flow-based tests create synthetic coverage for the destinations real traffic is actually reaching, so coverage stays aligned with user behavior as patterns shift.
How network synthetic monitoring differs from web and application synthetic monitoring
Web and application synthetic monitoring — the model behind tools built around Selenium, Playwright, or browser checks — is optimized for the front end, measuring statistics about page load, Core Web Vitals, and scripted user journeys against your own web properties. It answers questions like, “Is my application fast and functional?”
Network synthetic monitoring answers a broader question: “Is the network and internet path between users and the service healthy, and if not, where?” It emphasizes internet-layer tests (traceroute, DNS, BGP) and outside-in measurement from many vantage points, so it can distinguish an application problem from an ISP problem, a routing change, or a regional internet event. In practice, most mature teams use both — web synthetic monitoring for the front end, and network synthetic monitoring for everything between the user and the service.
Why network path analysis is the other half
A synthetic test that fails is only useful if you can see the path it took. That’s why network synthetic monitoring and network path analysis belong together. The test tells you an experience degraded, while the path shows you the route, the hops, and the AS-level transitions where it happened.
Traceroute-based tests produce hop-by-hop path data, and pairing that with AS-path visibility makes it possible to see which routing decisions correlate with better or worse performance. When a SaaS endpoint slows down for one region but not others, path analysis is what turns “Salesforce is slow” into “Salesforce is slow for users routed through ISP A because of a transit-path change at a specific AS.”
Correlating synthetic results with flow and BGP
The deepest value comes from correlating synthetic results with what’s actually happening on the network. When a synthetic test degrades, real flow data answers whether real users are affected and how many, while BGP monitoring shows whether a routing change explains the degradation.
This is the difference between an outside-in probe and network intelligence. Kentik displays synthetic test results, real flow telemetry, and BGP announcements on the same time axis, and its AI Advisor can investigate a degradation across synthetic, flow, BGP, and device data — so teams move from “a test failed” to an evidence-backed root cause, without switching tools.
Core use cases for network synthetic monitoring
Network synthetic monitoring earns its place when it’s tied to specific outcomes:
- SaaS reachability across ISPs and regions — run tests to SaaS endpoints from multiple internet cities and clouds to isolate whether an issue is provider-wide, ISP-specific, or regional.
- Best route to a provider across multiple ISPs — compare AS paths and performance across candidate ISPs to see which routing delivers the best experience.
- VoIP, video, and gaming quality of experience — run continuous, low-interval ping and traceroute tests along the paths real-time media takes, alerting on jitter and loss rather than average latency.
- Hybrid and multicloud connectivity — test between cloud regions, VPCs, and on-premises sites to catch latency and loss across paths you don’t fully control.
- SLA validation and outage detection — run scheduled tests against contractual targets and detect internet outages and reachability problems before users report them.
What to look for in a network synthetic monitoring tool
The strongest form of network synthetic monitoring isn’t just a standalone network of probes. It’s testing tied to the rest of your network telemetry. When evaluating solutions, look for:
- Global agent coverage in the geographies and networks your users actually inhabit, plus private agents for inside-out testing
- The full range of network test types (ping, traceroute, DNS, HTTP/API, page load, transaction, BGP)
- AS-path and path visibility so that failed tests are actionable
- Correlation with flow and routing data so you can tie a degraded test to real traffic and a specific route and
- AI-assisted investigation to shorten the path from alert to cause.
Best network synthetic monitoring tools by category
Synthetic monitoring tools cluster into categories, and the right one depends on whether your main concern is the front-end application or the network and internet path between users and services. The categories below group tools by their primary focus, rather than ranking them head to head.
Network and internet-path synthetics: Network Intelligence and Internet Performance Monitoring (IPM)
This is the category built for the network path itself — outside-in and inside-out testing, internet-layer tests, and routing context. Kentik leads here for teams that also need their own traffic and routing correlated with tests, pairing 300+ global agents and private agents with flow analytics and BGP. Cisco ThousandEyes and Catchpoint (now part of LogicMonitor) are the established internet performance monitoring platforms in this category, strong on large global vantage-point networks and outside-in measurement.
Cloud-native synthetics
Cloud providers offer synthetic checks tied to their own platforms — for example, Amazon CloudWatch Synthetics canaries and CloudWatch Network Monitor. These fit teams standardized on a single cloud that want basic synthetic and hybrid-connectivity checks inside their existing console, though cross-provider and internet-path depth is limited.
Full-stack observability with synthetics
Datadog, Dynatrace, New Relic, and Splunk include synthetic and RUM modules inside broader observability suites. They fit teams whose priority is application and infrastructure observability and who want synthetic checks tied to traces, logs, and APM — with a shallower view of the internet path than a purpose-built network or IPM tool.
Web and open-source synthetics
Pingdom, Checkly, Site24x7, and Uptrends handle website and API uptime and performance, while Grafana k6, Selenium, and Playwright drive scripted browser and load testing. These fit front-end and developer use cases where the requirement is web performance rather than network or internet-path visibility.
Where Kentik fits: if the goal is proving whether the network or internet path is the cause — and correlating that with your own traffic and routing — Kentik is the network intelligence option in this landscape. If the goal is primarily front-end web performance or endpoint experience, a web-synthetic or DEM tool is the better primary fit, often alongside Kentik for the network layer.
Related Kentipedia articles
- What is Synthetic Monitoring?
- What is Synthetic Transaction Monitoring (STM)?
- Synthetic Monitoring vs Real User Monitoring
- Network Path Analysis
- What is Digital Experience Monitoring (DEM)?
- Understand Internet Performance
- Best Network Monitoring Tools
FAQs about network synthetic monitoring
What is network synthetic monitoring?
Network synthetic monitoring is a proactive testing method that uses distributed agents to run scripted tests and network probes — ping, traceroute, DNS, HTTP, and multi-step transactions — that simulate user traffic and measure the performance, availability, and paths of applications and networks before real users are affected. It extends synthetic monitoring beyond the application to the network and internet path between users and the services they depend on.
How is network synthetic monitoring different from web or application synthetic monitoring?
Web and application synthetic monitoring focuses on the front end — page load, Core Web Vitals, and scripted journeys against your own web properties. Network synthetic monitoring adds the internet and network path, emphasizing tests like traceroute, DNS, and BGP and measuring from many vantage points, so it can tell whether a problem is the application, an ISP, or a routing change. Most mature teams run both.
Which synthetic tests isolate a network problem from an application problem?
Separating a path issue from an app issue takes network-layer tests, not just application checks: ping and traceroute expose latency, loss, jitter, and the hop-by-hop route; DNS tests catch resolution failures; and BGP monitor tests surface routing changes and lost reachability. HTTP, page load, and transaction tests then confirm whether the service itself responded. Running them side by side, from multiple vantage points, is what lets you attribute a slowdown to an ISP or a route rather than the application. Kentik runs all of these from global and private agents and ties them to AS-path visibility so the network-layer verdict is actionable.
How does network synthetic monitoring relate to network path analysis?
They are two halves of the same workflow: synthetic tests tell you that an experience degraded, and network path analysis shows the route it took and where along that route the problem occurred. Traceroute-based tests paired with AS-path visibility make it possible to see which routing decisions correlate with better or worse performance. Kentik supports this by showing latency over time alongside the AS paths active at each moment, so a performance shift can be tied to a specific path change.
Can synthetic monitoring detect problems on networks I don’t own?
Yes — that is one of its main strengths. Because tests run from agents distributed across the internet, they can measure the performance of paths through ISPs, cloud backbones, and SaaS platforms that you don’t control, and detect problems like regional degradation or routing changes that internal monitoring can’t see. Comparing results across locations makes it possible to isolate where a problem originates.
How do I find the best route to a SaaS provider across multiple ISPs?
When multiple ISPs can carry traffic to a SaaS provider, the AS path each takes — and its performance — often differ, so the approach is to run synthetic tests from agents on each candidate ISP and compare latency, loss, and AS paths. Kentik supports this with path views that show latency over time alongside the AS paths active at each time slice, making it possible to see which routing correlates with better performance.
How do I tell whether a degraded path is actually affecting real users?
A synthetic test shows a path degraded, but not how much it matters — that means overlaying the real traffic riding the same path and the routing state at that moment on one timeline. The approach is to line up synthetic results, flow data for the affected prefixes or ASNs, and BGP announcements against a shared time axis. Kentik supports this by storing synthetic, flow, and BGP data together, so a failed test can be tied to the volume of real traffic on that path and to any route change that coincided with it.
Where does network synthetic monitoring fit alongside real user monitoring (RUM)?
They answer different questions and are strongest together. RUM passively captures what real users experienced, but it can’t probe the ISPs, routes, and paths between users and a service, and it goes quiet when traffic is low. Network synthetic monitoring actively tests those paths on a schedule from controlled vantage points, so it can localize a problem to a specific ISP or AS even when no one is currently hitting the service. RUM tells you users are affected; network synthetic monitoring tells you where on the path it’s happening.
What should I look for in a network synthetic monitoring tool?
Look for global agent coverage in the geographies and networks your users inhabit plus private agents for inside-out testing, the full range of network test types, AS-path and path visibility so failed tests are actionable, correlation with flow and BGP so a degraded test can be tied to real traffic and a specific route, and AI-assisted investigation to shorten time to root cause. The most effective tools tie synthetic testing to the rest of your network telemetry rather than running it in isolation.
How does Kentik approach network synthetic monitoring?
Kentik runs synthetic tests — ping, traceroute, HTTP, DNS, page load, and Puppeteer-based transaction tests, plus BGP monitor tests — from 300+ global agents across AWS, GCP, Azure, OCI, and key internet hubs, plus private agents in customer infrastructure. What sets it apart is correlation: results are tied to real flow telemetry and BGP routing in one network intelligence platform, and autonomous, flow-based tests automatically follow the destinations real traffic is reaching, so synthetic coverage stays aligned with user behavior.
Monitor digital experience across your network with Kentik
Kentik is the network intelligence platform that pairs synthetic testing with real traffic and routing data — so you can prove whether the network or internet path is the cause, and fix it before users are affected.
- Get a demo — See network synthetic monitoring unified with flow, BGP, and AI
- Kentik Synthetics — Ping, traceroute, HTTP, DNS, page load, transaction, and BGP tests
- Kentik Global Synthetic Network — 300+ agents across AWS, GCP, Azure, OCI, and key internet hubs
- Understand Internet Performance — Internet-path visibility, BGP monitoring, and State of the Internet
- Kentik AI Advisor — Investigate degradations across synthetic, flow, BGP, and device data in natural language
