Passive monitoring tells you what happened on infrastructure you control. Synthetic monitoring tells you what users experience right now across paths you do not own — ISP transit, SaaS provider networks, DNS resolvers, and CDN edges between your branch offices and the applications they depend on. Proactive synthetic probes detect brownouts, DNS failures, and TLS certificate problems before helpdesk queues fill, transforming network operations from ticket-driven firefighting to measured service level management.
Synthetic monitoring generates controlled traffic on a schedule, measuring each step of connection establishment independently. A probe resolving a SaaS hostname, establishing TCP, completing TLS handshake, and receiving HTTP response reveals exactly which phase failed when users report vague slowness. Decomposing end-to-end latency into DNS, connect, SSL, and transfer components isolates failure domains that aggregate metrics like simple ping round-trip time obscure entirely.
Probe Architecture
Deploy synthetic agents at locations that matter — every branch office, major campus, cloud VPC regions, and home-office representative sites if remote work dominates. Hardware appliances provide consistent measurement conditions; software agents on existing infrastructure reduce cost at the expense of sharing CPU with production workloads. Cloud-based synthetic services probe from provider PoPs globally, supplementing but not replacing on-premise probes that reflect actual user path characteristics through corporate WAN and security stacks.
Each probe executes test definitions on configurable intervals — typically one to five minutes for critical SaaS dependencies, longer for lower-priority targets. Tests specify protocol, target hostname or IP, expected response codes, certificate validation requirements, and custom headers for authenticated endpoints. Distributed probes from multiple sites simultaneously reveal whether failures are local to one branch, regional to an ISP, or global to the SaaS provider.
Measurement Types
DNS resolution time measures how long the probe's configured resolver takes to return an answer. Spikes indicate resolver problems, authoritative server issues, or DNS-based filtering interference. TCP connect time to the resolved IP isolates network path problems from application-layer issues. TLS handshake duration captures certificate negotiation and cipher establishment — sudden increases may indicate certificate renewal problems or middlebox SSL inspection degradation.
HTTP response time and status code validation confirm application availability beyond network reachability. Transaction scripting extends probes to log in, navigate workflows, and verify response content — catching application failures that return HTTP 200 with error pages. VoIP and video synthetic tests use UDP jitter and packet loss measurements mimicking real-time traffic characteristics that TCP-based HTTP probes cannot represent.
WAN and Path Monitoring
Multi-site enterprises probe the same SaaS targets from every branch, building a matrix of path performance. A SaaS application slow from one branch but fast from headquarters implicates that branch's ISP or local internet breakout, not the SaaS provider. Compare synthetic results with SD-WAN path selection logs to verify traffic engineering policies route applications over intended links. MPLS versus broadband performance differences become quantified rather than anecdotal.
Probe between your own sites to measure inter-branch latency and loss independent of third-party services. Full-mesh probing scales poorly — probe from each branch to two or three representative hubs rather than every pair. Anycast and geo-DNS services require probes from diverse geographic locations to validate that users receive nearby endpoints rather than distant ones due to misconfigured DNS views.
Alerting and SLIs
Define service level indicators with thresholds based on baseline performance, not arbitrary numbers. Alert when DNS resolution exceeds twice the thirty-day median for three consecutive probe cycles, not when it exceeds a fixed fifty milliseconds that may be normal for some paths. Separate alerts by failure type — DNS failure, TCP timeout, TLS error, HTTP 5xx — so responders know immediately which escalation path to follow.
Correlate synthetic alerts with ISP maintenance notifications, BGP route changes, and certificate expiration calendars. Many synthetic failures have known external causes that do not require internal investigation if correlation is immediate. Track mean time to detect and mean time to resolve for synthetic-identified incidents versus user-reported incidents — the gap quantifies monitoring program value to leadership.
Tooling and Integration
ThousandEyes, Catchpoint, Datadog Synthetics, and open-source Smokeping with custom scripts serve different scale and budget requirements. Integrate synthetic results into NOC dashboards alongside SNMP and flow data. Create runbooks mapping each synthetic test to application owner contacts and expected escalation procedures. Store historical synthetic data for at least one year to support trend analysis during annual architecture reviews and WAN contract renegotiations.
Synthetic monitoring does not replace passive observability — it complements it by answering the question users actually care about: can I reach what I need to do my job from where I am working right now? Networks that probe proactively spend less time asking users to reproduce problems and more time fixing the path components synthetic data already identified.
Building the Business Case
Quantify synthetic monitoring value by tracking incidents detected by probes before user reports and estimating avoided downtime cost. A single prevented hour of company-wide SaaS outage during business hours often exceeds annual synthetic monitoring platform licensing. Present this data to finance during budget cycles rather than requesting monitoring tools as pure infrastructure overhead without business outcome connection.
Define ownership clearly — network teams typically operate probes and interpret path performance, while application teams own transaction scripts and response validation for business workflows. Shared dashboards prevent the common failure mode where synthetic monitoring deploys successfully but nobody reviews results until executives ask why the investment was made.
Extend synthetic monitoring to internal API dependencies and microservices, not only SaaS and WAN paths. East-west service mesh latency and database connectivity from application tier probes catch problems invisible to edge-only monitoring. Kubernetes synthetic agents as CronJobs executing HTTP checks against cluster services provide application-layer visibility complementing infrastructure SNMP and node-level health checks.
Baseline and Seasonality
Establish performance baselines during known-good periods rather than immediately after deployment when configuration may still be settling. Account for seasonality — retail networks peak during holidays, education networks peak during enrollment — when setting alert thresholds. Static thresholds appropriate in January may generate false positives during December traffic patterns or vice versa.
Review synthetic test targets quarterly as application portfolios change. Retired tests pointing at decommissioned endpoints generate noise; missing tests for new critical dependencies create monitoring gaps discovered only during outages. Maintain a synthetic test catalog linked to application inventory with ownership assignments for each monitored service.