Monitoring and operating SD-WAN: link health, application SLAs and troubleshooting

Why SD-WAN needs its own monitoring approach

In a traditional WAN a link is either up or down, and a ping test tells you most of what you need. SD-WAN is more subtle. A link can be up but losing 3% of packets, and the SD-WAN quietly moves voice away from it. Users are fine, but you are now running on one good link without knowing it. Good monitoring shows these hidden problems before the second link fails too.

Metrics that matter

The thresholds above are common starting points for voice and video, not fixed rules. Set your own from each application's needs.

Where the data comes from

• The SD-WAN controller or dashboard: the richest view of tunnels, applications and policy decisions, because the edge devices already measure every path.
• Traditional monitoring tools: SNMP polling, syslog and flow records (NetFlow or IPFIX) from edge devices feed your existing network monitoring system, so WAN health sits next to switches, servers and Wi-Fi in one place.
• Streaming telemetry and APIs: many platforms push metrics or expose them through a REST API for your own dashboards.
• Digital experience monitoring (DEM): agents on laptops or synthetic tests that measure how long a real application takes to respond, from the user's point of view.

Tip: alert on trends and sustained problems (for example "loss above 2% for 10 minutes" or "this site has been on its backup link for an hour"), not on every brief spike. Too many alerts and people stop reading them.

A troubleshooting order

1. Start with the user: which application, which site, since when? Is it one user or the whole site?
2. Check the application policy: was the traffic recognised correctly and sent down the expected path?
3. Check the overlay: are tunnels from that site up, and what are their loss, latency and jitter?
4. Check the underlay: link status, errors and utilisation, and whether the provider reports a fault.
5. Check beyond the WAN: the cloud security service, DNS or the SaaS provider itself.

Keep a record of every fault and what fixed it. Over time this shows which links and providers cause most trouble.

Real-world example: the quiet failover

A fictional engineering firm noticed nothing wrong at its coastal office, because SD-WAN kept moving video calls to the 5G backup. Its weekly report, however, showed that site's broadband had violated the voice SLA on 40 occasions in seven days, always in the late afternoon. Flow data ruled out internal congestion, so the team raised a fault with the provider, supplying the loss and jitter graphs. The provider found a faulty card in the local aggregation equipment. Without the report, the office would have discovered the problem only when the 5G link also had an outage.