Effective SD-WAN monitoring delivers unified overlay and underlay visibility, SLA-driven alerts, and continuous validation so you can detect and prove root cause before users complain. This guide covers what to measure, how to collect it, and how to operationalize monitoring so your SD-WAN deployment consistently meets SLA commitments. According to best practices for operating SD-WAN networks, continuous validation via active probes and historical baselines is what separates teams that catch problems early from those reacting to user complaints.
Five elements every SD-WAN monitoring program must cover:
- Overlay metrics: tunnel health, SLA path assignments, controller status
- Underlay metrics: circuit latency, jitter, packet loss per transport link
- Tunnel and SLA path visibility: per-application path scorecards and trend data
- Device health: CPU, memory, interface errors, and configuration state
- Automated alerts: threshold-crossing notifications tied to SLA classes
3-step coverage validation you can run in under 30 minutes:
- Pull a live tunnel list from your controller and confirm every active tunnel shows bidirectional path metrics (latency, jitter, loss) updated within the last 10 seconds.
- Run an independent synthetic probe from at least one site to a known destination and compare results against controller-reported path quality for the same path.
- Verify that at least one alert rule exists for each SLA class, fires on a test threshold breach, and routes to the correct team or ticket queue.
Key Takeaways
Effective SD-WAN monitoring requires independent overlay and underlay visibility, baseline-driven alerting, and continuous synthetic validation deployed before the first migration site goes live.
| Point | Details |
|---|---|
| Baseline before migration | Deploy synthetic probes and capture at least two weeks of pre-migration data to enable meaningful before/after comparisons. |
| Monitor underlay independently | Controllers mask circuit degradation; SNMP, NetFlow, and site-resident synthetic agents reveal what the overlay hides. |
| Use SLA-driven alert thresholds | Set thresholds per site from baseline data, not generic defaults, to reduce false positives and catch real degradation faster. |
| Maintain device inventory | Track software version, configuration hash, and last change timestamp for every edge device to detect drift before it causes an outage. |
| Netverge unifies the full stack | Netverge combines controller API ingestion, Vergepoint synthetic probes, flow analytics, and AIOps triage in one platform for MSPs and enterprises. |
Table of Contents
- What does SD-WAN monitoring actually need to measure?
- How do you monitor overlay and underlay separately?
- What should your SD-WAN dashboards and reports show?
- How should you configure alerts and detect SLA threshold crossings?
- What edge device telemetry do you need to track?
- What capabilities should you require from an SD-WAN monitoring solution?
- When and how should you onboard monitoring for SD-WAN?
- How do you troubleshoot SD-WAN incidents and find root cause fast?
- How does Netverge address the SD-WAN monitoring checklist?
- The monitoring gap most teams discover too late
- Netverge gives your team full SD-WAN visibility from day one
- Sources
What does SD-WAN monitoring actually need to measure?
The metrics that matter most are latency, jitter, packet loss, throughput utilization, MOS for voice, and tunnel availability. Each one tells a different story about what users are experiencing and where the problem likely lives.
MEF-105, the SD-WAN performance monitoring standard, specifies measurement intervals of 10 seconds or less for tunnel and application flow monitoring, and requires metrics to be collected in both directions. That interval is significantly shorter than traditional SOAM measurement cycles, and for good reason: SD-WAN path switches happen in seconds, so a 60-second polling cycle will miss the event entirely.
What each metric signals:
- Latency reflects propagation delay plus queuing. Spikes above 150 ms on a voice path usually produce audible degradation before MOS drops below 3.5.
- Jitter measures variation in packet arrival timing. Values above 30 ms on a real-time path indicate buffer stress or inconsistent transport behavior.
- Packet loss above 1% on a business-critical path is a hard escalation trigger. Even 0.5% sustained loss degrades TCP throughput noticeably on high-bandwidth transfers.
- Throughput utilization tells you whether a path is approaching saturation. Sustained utilization above 80% on a primary transport link is a capacity planning signal, not just a performance one.
- MOS (Mean Opinion Score) aggregates latency, jitter, and loss into a single voice quality indicator. Scores below 3.5 correlate with user complaints; below 3.0, calls become unusable.
- Tunnel availability tracks whether a given tunnel is up, degraded, or failed. Combined with path preference data, it shows whether the controller is routing traffic as policy intends.
Key SD-WAN performance metrics for enterprise networks confirms that tracking these metrics together enables proactive remediation for business-critical applications, rather than reactive firefighting after users escalate.
| Metric | Warning Threshold | Escalation Threshold | Primary Root Cause |
|---|---|---|---|
| Latency (one-way) | Above typical thresholds | Above critical thresholds | ISP congestion, routing change |
| Jitter | Above normal variance levels | At levels indicating transport issues | Transport instability, QoS misconfiguration |
| Packet loss | Above minor impact level | At levels requiring escalation | Circuit degradation, hardware fault |
| Throughput utilization | Approaching capacity | Sustained near saturation | Capacity shortfall, traffic spike |
| MOS | Below acceptable quality | At unusable levels | Compound latency/jitter/loss issue |
| Tunnel availability | Any instability | Sustained outage | Underlay failure, policy conflict |
How do you monitor overlay and underlay separately?
The overlay is what the SD-WAN controller sees: tunnels, SLA classes, path preferences, and application steering decisions. The underlay is what the ISP delivers: raw circuit performance, BGP peering state, and physical interface health. Controllers can mask underlay problems by rerouting traffic before your monitoring system registers the degradation. That is why monitoring both layers independently is a non-negotiable requirement, not an optional enhancement.
Overlay: what to collect and how
- Controller status and reachability (REST API health checks)
- Tunnel state per site pair: up/down, path preference, SLA class assignment
- Per-tunnel metrics: latency, jitter, packet loss, MOS (via controller REST API or event streams)
- Application flow steering events: which SLA class a flow was assigned to and whether it was honored
- Policy change events: any modification to path preference rules or SLA class definitions
Collect overlay data through your controller's REST API. Most major SD-WAN platforms expose tunnel and SLA path statistics via authenticated API endpoints. Poll at the MEF-105-recommended interval of 10 seconds or less for real-time accuracy.
Underlay: what to collect and how
- Per-interface traffic counters: input/output rates, errors, discards (SNMP)
- Circuit-level flow data: top talkers, application mix, utilization per transport link (NetFlow, sFlow, or IPFIX)
- Synthetic path probes: IP SLA operations or equivalent active tests from site to site and from site to SaaS endpoints
- BGP peering state for sites using direct internet access or MPLS hand-off
- Physical interface errors and CRC counts as early indicators of circuit degradation
Pro Tip: Place synthetic monitoring agents on the same subnet as end users, not on the SD-WAN device itself. An agent co-located with users captures the actual path experience, including any local switching or VLAN issues the device-level probe would miss. Secure all API credentials with role-limited service accounts and rotate them on the same schedule as your other infrastructure credentials.
Monitoring agents placed at sites, independent of the controller, validate true path behavior and confirm whether a controller reroute actually resolved user impact or only shifted congestion to a different circuit. The AppNeta SD-WAN monitoring guide recommends using both single-ended probes (site to SaaS) and dual-ended probes (site to site) to eliminate blind spots.
What should your SD-WAN dashboards and reports show?
Dashboards are where overlay and underlay data converge into something a NOC engineer can act on in under two minutes. SD-WAN dashboards should expose tunnel statistics and application/SLA path statistics with jitter, latency, and packet loss alongside maps, scorecards, and drilldowns for root-cause analysis.
Essential dashboard widgets for a NOC:
- Site map with color-coded path health (green/yellow/red per site and per transport link)
- Tunnel list view: all active tunnels with current latency, jitter, loss, and SLA class
- SLA path scorecards: per-application class compliance over the last 24 hours and 7 days
- Top-N sites by packet loss or jitter (updated in near real time)
- Active alerts panel with severity, affected site, and time-to-acknowledge
Engineering-level drilldowns to include:
- Per-tunnel trend charts (30-day latency and jitter history)
- Flow correlation view: which applications are using which tunnels and at what volume
- Underlay circuit utilization overlaid with overlay path quality for the same time window
- Configuration change log with timestamps and operator attribution
Unified dashboards that correlate controller data with flow and device telemetry reduce mean time to innocence by giving engineers a single view rather than requiring them to pivot across three separate tools. The IBM SevOne SD-WAN monitoring guide highlights this correlation capability as a primary driver of faster resolution for MSP and enterprise teams.
For reporting, three use cases drive the most operational value: daily health summaries for NOC shift handoff, SLA compliance reports for ISP and carrier review meetings, and pre/post migration comparisons that quantify the impact of SD-WAN versus legacy MPLS. Role-based dashboards matter here. A NOC analyst needs real-time alerts and site status. A network engineer needs trend data and drilldowns. A service delivery manager needs SLA compliance percentages and exception counts. Build separate views rather than one dashboard that tries to serve all three.
How should you configure alerts and detect SLA threshold crossings?
Static thresholds are a starting point, not a finished alerting strategy. A latency alert set at 150 ms for every site will fire constantly for a remote site in Hawaii and never fire for a degraded link in Chicago that normally runs at 20 ms. Adaptive thresholds, calculated from each site's own historical baseline, produce far fewer false positives and catch real degradation faster.
Alert workflow: detection to remediation
- Detect: Threshold crossing fires on a per-site, per-metric basis (latency, jitter, loss, MOS, tunnel state).
- Enrich: The alert system appends context: affected site, transport link, SLA class, current controller path preference, and recent configuration changes.
- Route: Enriched alert goes to the correct team (NOC for active incidents, engineering for capacity trends) or creates a ticket automatically in the ITSM platform.
- Correlate: The system checks whether the alert correlates with a known underlay event (SNMP trap, BGP flap, synthetic probe failure) or a controller policy change.
- Remediate: Automated playbooks handle well-defined scenarios (restart a failed tunnel, escalate to ISP, notify on-call). Human review handles ambiguous or novel conditions.
Policy-change detection deserves its own alert category. When a controller automatically reroutes traffic due to SLA degradation, that event should generate a notification even if the reroute succeeds. A silent failover that you only discover during the next day's report is a gap in operational awareness.
Pro Tip: Suppress alert storms during planned maintenance windows by tagging maintenance events in your monitoring platform before the change window opens. An untagged maintenance window that triggers 200 alerts trains engineers to ignore alerts, which is the fastest way to miss a real incident.
For real-time SD-WAN monitoring to deliver on its promise, alert fatigue must be managed deliberately. AIOps-driven event correlation, which groups related alerts into a single incident rather than flooding the queue, is now a standard expectation for any monitoring platform serving multi-site SD-WAN deployments.
What edge device telemetry do you need to track?
Every SD-WAN edge device is both a network function and a managed asset. Treating it only as a network function means you will miss configuration drift, approaching end-of-support, and hardware stress signals until they become outages.
Device inventory checklist (capture at onboarding, refresh on every change):
- Hardware model and serial number
- Current software version and target version per policy
- Configuration hash (to detect unauthorized or untracked changes)
- Last configuration change timestamp and operator ID
- Provisioning status: managed, unmanaged, or pending
Device health metrics to poll continuously:
- CPU utilization: sustained above 80% indicates traffic or process overload
- Memory utilization: above 85% risks process crashes on lower-spec edge hardware
- Disk utilization: relevant for devices logging locally
- Interface error and discard counters: rising CRC errors or input discards signal physical layer problems
- Temperature and fan status where the hardware exposes them via SNMP or REST
Configuration drift detection procedure:
- Capture a known-good configuration hash for each device at the end of each approved change window.
- Poll configuration state on a scheduled basis (every 15 minutes is practical for most deployments).
- Alert immediately when the current hash differs from the baseline hash.
- Trigger an automated ticket that includes the device ID, the time of change, and the diff if your platform supports it.
- Require engineer sign-off to update the baseline hash, creating an auditable change record.
Integrating device lifecycle data with incident workflows means that when an edge device opens a ticket for high CPU, the ticket automatically includes the device's software version, last config change, and whether it is within its support lifecycle. That context cuts triage time significantly.
What capabilities should you require from an SD-WAN monitoring solution?
Evaluating monitoring tools against a capability checklist prevents you from discovering gaps after deployment. The checklist below maps to the operational requirements covered throughout this guide.
Functional capability checklist:
- Controller REST API ingestion for overlay metrics (tunnel state, SLA path, policy events)
- SNMP polling for device and interface health
- NetFlow, sFlow, or IPFIX collection for flow-level visibility
- Synthetic test execution (IP SLA or equivalent active probes) from site-resident agents
- Overlay and underlay correlation in a single view, not separate tools
- AIOps-driven event correlation to group related alerts into single incidents
- Role-based dashboards with multitenancy support for MSP or multi-team environments
- Automated ticketing integration with ITSM platforms
- Historical data retention sufficient for pre/post migration comparisons (minimum 90 days)
Integration requirements:
- Authenticated REST API connections to SD-WAN controllers
- SNMP v2c or v3 for device polling
- Flow collector supporting NetFlow v9, IPFIX, or sFlow
- Synthetic agents deployable at remote sites without requiring a full server
- Webhook or API hooks to ticketing platforms for automated incident creation
Evaluation questions for RFP or vendor demos:
- What is the platform's mean time to detect (MTTD) for a tunnel failure, and how is that measured?
- Can the platform correlate an overlay path switch with the underlay event that caused it, in a single view?
- How does the platform handle alert storms during a multi-site outage? Does it group related events automatically?
- What is the maximum polling interval for tunnel metrics, and does it meet the MEF-105 recommendation of 10 seconds or less?
- How does the platform support pre/post migration baseline comparisons?
- What automated remediation actions are available out of the box, and how are custom playbooks created?
For teams evaluating key features of network management platforms, the answers to questions 2 and 3 above are the fastest differentiators between tools that reduce MTTI and tools that only report what already happened.
When and how should you onboard monitoring for SD-WAN?
The answer to "when" is unambiguous: before the first site goes live. Deploying monitoring before the first SD-WAN migration enters production is the only way to capture pre-migration baselines that make post-migration comparisons meaningful. Without a baseline, you cannot prove whether SD-WAN improved performance or shifted the bottleneck.
Phased onboarding steps:
- Pre-deployment discovery: Inventory all sites, transport links, and existing devices. Document current latency, jitter, and loss per circuit using IP SLA operations or equivalent synthetic tests.
- Baseline capture: Run synthetic probes for at least two weeks before migration to establish normal ranges for each site and each SLA class.
- Synthetic agent placement: Deploy monitoring agents at pilot sites on the same subnet as users. Confirm both site-to-site and site-to-SaaS probe paths are active.
- Staged activation: Bring sites into monitoring incrementally. Validate dashboard coverage and alert routing for each site before proceeding to the next batch.
- Post-cutover validation: Compare post-migration metrics against the pre-migration baseline for each site. Document results for leadership and ISP review.
Baseline checklist:
- IP SLA operations running for all primary and backup transport links
- Synthetic probes covering all SLA classes (voice, video, business-critical, best-effort)
- Historical traffic baselines per site (peak and average utilization)
- SLA class mapping documented: which applications belong to which class
- Alert thresholds set per site based on baseline, not generic defaults
For network infrastructure monitoring at scale, collector sizing matters. A single flow collector handling hundreds of sites will drop records under load. Plan for distributed collectors or cloud-based aggregation, and validate that your polling architecture can sustain the MEF-105 10-second interval across all sites simultaneously.
How do you troubleshoot SD-WAN incidents and find root cause fast?
The most common mistake in SD-WAN troubleshooting is starting with the controller. Controllers report what the overlay sees, not what the underlay is doing. A mature troubleshooting workflow starts with user impact, then works through overlay evidence, then validates the underlay independently.
Stepwise troubleshooting workflow:
- Confirm user impact: Check synthetic probe results and application performance data for the affected site. Confirm that real traffic is degraded, not just a monitoring anomaly.
- Check tunnel and SLA path health: Review the tunnel list for the affected site. Identify which SLA class is affected and whether the controller has already rerouted traffic.
- Validate underlay circuits: Pull SNMP interface counters and synthetic probe results for each transport link at the affected site. Look for error spikes, utilization saturation, or probe failures independent of the controller view.
- Correlate flows and controller events: Cross-reference NetFlow or IPFIX records with controller event logs. Confirm whether the application traffic is actually using the path the controller reports.
- Apply mitigations: If underlay degradation is confirmed, engage the ISP with timestamped probe data. If the issue is a policy misconfiguration, roll back the change and document the impact.
Root-cause evidence sources:
- Flow records (NetFlow/IPFIX): confirm actual application path and volume
- Controller event logs: policy changes, tunnel state transitions, SLA class reassignments
- SNMP traps and interface counters: physical layer errors, link flaps
- Synthetic probe results: independent path quality measurements unaffected by controller rerouting
Pro Tip: When a controller reroutes traffic and the user impact persists, the problem is almost always in the underlay. Run a synthetic probe directly over the secondary transport link before assuming the reroute failed. Controllers reroute correctly far more often than they are blamed for; the circuit is usually the culprit.
For postmortem documentation, a minimal incident template should capture: affected sites and SLA classes, time of first user impact versus time of first alert, root cause (overlay policy, underlay circuit, or device hardware), resolution steps taken, and any monitoring gap that delayed detection. A network performance management workflow that includes postmortem templates reduces repeat incidents by making root causes searchable and actionable.
How does Netverge address the SD-WAN monitoring checklist?
Netverge maps directly to the capability requirements outlined in this guide. The platform collects overlay metrics via controller REST APIs, polls device health via SNMP, ingests flow data for application-level visibility, and deploys Vergepoints as site-resident hardware agents that run synthetic probes independently of the SD-WAN controller.
Netverge capabilities mapped to operational requirements:
- Overlay and underlay correlation: A single dashboard view combines controller tunnel data with SNMP, flow, and synthetic probe results, so engineers do not pivot between tools during an incident.
- 28+ specialized sensors: Cover tunnel health, interface errors, flow analytics, device CPU and memory, and SLA path compliance in a single agent deployment.
- Vergepoints for underlay validation: Physical edge hardware placed at sites runs independent synthetic probes, capturing true path quality from the user subnet rather than from the device management plane.
- AIOps event correlation: The platform groups related alerts into single incidents and applies AI-driven triage to identify probable root cause before a ticket is assigned to an engineer.
- AI ticket triage: Incidents are automatically enriched with device context, recent configuration changes, and correlated underlay events, then routed to the correct queue without manual sorting.
- Multitenancy and role-based dashboards: MSPs can manage multiple customer environments from a single interface, with role-appropriate views for NOC analysts, engineers, and service delivery managers.
Pro Tip: Deploy Vergepoints at pilot sites during the pre-migration baseline phase. The synthetic probe data they generate becomes your pre-migration benchmark, and the same agents continue running post-cutover, giving you a direct before/after comparison without any instrumentation changes.
For teams managing network monitoring trends and evaluating where AI fits in their operations, Netverge's autonomous agents go beyond alerting: they diagnose, document, and in defined scenarios, remediate without waiting for engineer intervention.
The monitoring gap most teams discover too late
The operational reality for most NOC teams is that SD-WAN monitoring gets deployed after the migration, not before. The controller dashboard goes live, a few SNMP polls get configured, and the team assumes coverage is complete. Then a circuit degrades, the controller reroutes silently, and three days later someone notices that voice quality at a branch has been marginal since the cutover. The synthetic probe that would have caught it in 30 seconds was never deployed.
The gap is not a tool problem. It is a sequencing problem. Teams that treat monitoring as a post-migration task are structurally unable to prove whether SD-WAN delivered its promised improvement, because they have no pre-migration baseline to compare against.
The second gap is subtler: trusting the controller as the source of truth for underlay health. Controllers are designed to abstract the underlay. That abstraction is the product's value. Independent underlay probes, placed at sites and running continuously, are the only way to see through that abstraction.
The teams that operate SD-WAN most effectively treat baseline capture and independent underlay validation as non-negotiable prerequisites, not optional enhancements. Everything else, including AIOps, automated remediation, and role-based dashboards, delivers more value when it sits on top of that foundation.
Netverge gives your team full SD-WAN visibility from day one
Most teams piece together SD-WAN visibility from three or four separate tools, then spend the first 20 minutes of every incident figuring out which tool has the relevant data. Netverge eliminates that by combining overlay telemetry, underlay synthetic probes, flow analytics, and AI-driven triage into a single platform built for MSPs and multi-site enterprises.
Vergepoints deploy at remote sites in minutes and immediately begin capturing independent path quality data, giving you the pre-migration baseline and the post-cutover comparison in the same interface. The Netverge monitoring platform covers the full checklist from this guide: controller API ingestion, SNMP polling, NetFlow collection, synthetic probes, AIOps event correlation, and role-based dashboards with multitenancy. Automated ticketing and triage routes enriched incidents to the right engineer without manual sorting.
Start with a pilot at two or three sites, validate your baseline capture, and map your SLA classes to alert thresholds before your next migration window. Request a demo or start a free trial at Netverge.
Sources
The following references provide deeper technical detail on the standards, operational practices, and platform guidance covered in this guide.
- DX NetOps Monitoring SD‑WAN Performance: Key Considerations and Best Practices