Predict Outages: 4 SD‑WAN SLA Metrics Network Engineers Must MonitorThe metrics that matter are latency, jitter, packet loss, and measured information rate (MIR). SD-WAN controllers use these four numbers to classify each tunnel into an SLA class, then steer voice, video, and transactional traffic away from paths that breach their thresholds. Your monitoring goal is simple to state and hard to execute: build a real baseline, catch threshold crossings before users complain, and let automated steering or alerting do the first response.

TL;DR:

Maintaining a baseline over multiple weeks with consistent probe types ensures accurate pre- and post-migration performance comparisons.

Thresholds for latency, jitter, and loss should be tailored to the specific application class, with tighter limits for voice and video traffic.

Combining overlay (controller) and underlay (network counters and flow telemetry) monitoring reduces false positives and clarifies actual issues.

Shorter calculation and reclassification intervals benefit real-time traffic but increase sensitivity to transient noise, requiring careful tuning.

Using multiple measurement tools and verifying with physical layer data prevents misdiagnosis and improves SLA compliance reporting.

What Are the Core SD-WAN SLA Metrics?
How Do Engineers Actually Measure These Metrics?
How Do SLA Classes Decide Which Path Traffic Takes?
Calculation Intervals and Reporting Cadence: What MEF-105 Actually Requires
How Do You Build a Monitoring Architecture That Doesn't Cry Wolf?
Building the Operational Runbook: From Baseline to Remediation
What Configuration Values Should You Actually Use?
How Does a Managed Provider Actually Run This in Practice?
What Actually Trips Up Teams Instrumenting This for the First Time
Get Help Monitoring SLA Metrics Across Every Site
Sources
FAQ

What Are the Core SD-WAN SLA Metrics?

Every SD-WAN SLA conversation starts with the same four numbers, and if you only remember one thing from this article, remember that they measure different failure modes. Latency tells you how long a packet takes to cross the network. Jitter tells you how consistent that timing is. Packet loss tells you how much data never arrives at all. MIR tells you whether the pipe itself is big enough for what you're asking it to carry. Miss any one of them and you'll misdiagnose the problem every time.

Latency is usually reported two ways: one-way delay and round-trip time (RTT). Round-trip is easier to measure because a single probe can do it without clock synchronization between endpoints, but one-way delay matters more for real-time applications where the forward and reverse paths take different routes (common with asymmetric internet circuits or MPLS/broadband hybrid tunnels). MEF 105 defines one-way mean packet delay as a standard metric precisely because averaging RTT and dividing by two hides asymmetric path problems.

Jitter is the variation in that delay from packet to packet, not the delay itself. A link with 80ms latency and near-zero jitter carries a voice call fine. A link with 40ms average latency but wild swings between 10ms and 90ms will produce choppy audio and dropped video frames, because codecs buffer to a fixed window and anything outside that window gets discarded. Voice and video are jitter-sensitive; a bulk file transfer barely notices it.

Packet loss needs to be split into forward loss and reverse loss, and separately, into inline loss versus probe loss. Inline loss comes from actual production traffic counters on the interface. Probe loss comes from synthetic test packets sent between SD-WAN edges. They usually track closely, but during partial outages or ISP-side congestion, probe loss can under-report or over-report relative to what real user traffic is experiencing, depending on how the carrier treats synthetic traffic in its queuing policy.

Measured Information Rate (MIR) is the one engineers most often skip, and it's the one that explains the mystery tickets. A tunnel can pass every latency, jitter, and loss threshold and still choke a video conference simply because the circuit is saturated. MIR monitoring catches capacity exhaustion before it shows up as loss.

MOS (Mean Opinion Score), a 1 to 5 scale, isn't a raw network metric at all. It's a derived score, usually calculated from latency, jitter, and loss together using models like E-model, that approximates what a human would rate a call's audio quality. Treat MOS as your translation layer between raw SLA metrics for SD-WAN and something a help desk ticket can actually reference.

Latency: one-way delay for real-time apps, RTT for general health checks
Jitter: inter-packet delay variation, critical for voice and video
Packet loss: split by direction and by inline vs. probe source
MIR: capacity headroom, not just quality of the bits that get through
MOS: a derived voice/video quality score built from the metrics above

How Do Engineers Actually Measure These Metrics?

You have five practical measurement tools, and none of them alone gives you the full picture. Overlap them.

ICMP/ping is the oldest and least trustworthy of the group. It's universally supported and easy to script, but many carriers rate-limit or deprioritize ICMP, and a router's control plane can process ping replies more slowly than actual data-plane traffic, producing latency numbers that don't reflect reality. Use it as a coarse liveness check, never as your SLA source of record.

BFD (Bidirectional Forwarding Detection) is what most SD-WAN controllers actually rely on for tunnel liveness and fast failure detection, and vendor platforms extend it to carry latency, jitter, and loss data alongside the liveness signal. Cisco's Catalyst SD-WAN documentation describes SLA classes built directly from BFD-derived polling, with a default poll interval and a sliding window of six poll cycles used to smooth out single bad samples before a tunnel gets reclassified, per Cisco's application-aware routing configuration guide. The BFD Hello interval and the poll interval interact more than most engineers assume: a very short poll window paired with too few Hello packets per cycle produces noisy, statistically unstable loss and latency numbers, so keep the sample count per calculation window high enough to mean something.

TWAMP (Two-Way Active Measurement Protocol) and its lighter cousin, TWAMP-lite, give you standardized one-way and round-trip measurement between a controller (session sender) and a reflector, with tighter timestamp precision than ICMP. It's the closest thing to a carrier-grade measurement standard available on SD-WAN edges, and it's the right tool when you need defensible numbers for a carrier SLA dispute.

TCP/UDP echo probes step past synthetic traffic entirely and extract metrics from real sessions, things like TCP init-failure rate and application RTT pulled from the actual handshake. Palo Alto's Prisma SD-WAN documentation shows this combined approach protecting a business-critical SaaS application by correlating link-quality metrics with real application-layer signals like init-failure rate and RTT, rather than trusting synthetic probes alone, per Palo Alto's SaaS protection use case.

Inline counters and flow telemetry (NetFlow, IPFIX, or vendor-specific flow records) round out the picture with actual production traffic statistics rather than synthetic samples.

Start with BFD for liveness and baseline SLA classification on every tunnel.
Layer TWAMP where you need audit-grade, carrier-facing numbers.
Add TCP/application probes for any SaaS app that's genuinely business-critical.
Pull flow telemetry continuously to validate that probe results match real traffic behavior.
Reserve ICMP for basic reachability checks only, not SLA compliance.

Pick probe destinations carefully. Probing only your own data center hides problems specific to a SaaS provider's network path, and probing only a public target like a DNS resolver hides problems specific to your own WAN edge. Use both.

Pro Tip: Don't rely on whatever probe types your controller's GUI exposes by default. Several platforms, Fortinet's FortiGate among them, hide additional probe types like TCP-echo and UDP-echo behind CLI configuration that the web interface never surfaces, and those probes often produce better measurement fidelity than the GUI defaults.

How Do SLA Classes Decide Which Path Traffic Takes?

An SLA class is a named bundle of thresholds, latency ceiling, jitter ceiling, loss ceiling, that the controller compares against every tunnel's live measurements to decide whether that tunnel is fit to carry a given traffic type. This is the mechanism behind application-aware routing: define an SLA class called "voice," attach it to your VoIP traffic policy, and the controller automatically steers calls away from any tunnel currently violating that class.

Typical threshold patterns roughly correspond to ranges appropriate for voice, transactional, and bulk traffic, with tighter constraints for voice and looser for bulk, but exact numbers depend on your applications and circuit types.

Those bands aren't arbitrary; they roughly track the point at which human perception of call quality and application responsiveness starts degrading. Versa's SLA profile documentation lets you set delay, jitter, forward loss, and reverse loss independently, plus a circuit utilization ceiling, and pairs each profile with a recomputation timer that determines how quickly a tunnel can be reclassified after conditions change, per Versa's SLA profile configuration guide.

The sliding-window aggregation matters more than engineers give it credit for. Cisco's model averages across six poll intervals before declaring a tunnel out of compliance, which smooths transient spikes but also means a genuine short outage might not trigger reclassification for several minutes depending on your poll interval. That's a deliberate tradeoff: fewer false positives from a single bad sample, at the cost of slower reaction to real, brief degradations. Many platforms also expose variance or tolerance fields specifically to reduce sensitivity to one-off spikes without loosening the underlying SLA class threshold.

When a tunnel breaches its assigned SLA class, the controller doesn't just alarm, it acts. Traffic gets rerouted to the best remaining compliant tunnel, or if none qualifies, to the least-bad option available, often with a log entry and an SNMP trap or API event you should be capturing downstream.

SD-WAN traffic rerouting after SLA breach

Calculation Intervals and Reporting Cadence: What MEF-105 Actually Requires

MEF-105 doesn't just define which metrics to measure; it defines the timing discipline that makes those metrics comparable across providers and time periods. The standard requires a Performance Metric Calculation Instance, essentially a defined window over which raw samples get aggregated into one metric value, and a separate Report Interval, the cadence at which those calculated values get delivered or displayed. Provider and subscriber are expected to agree on both before comparing numbers, because a five-minute average and a one-hour average of the same link tell very different stories.

MEF-105 requires that calculation intervals and reporting durations be explicitly defined and agreed between provider and subscriber, precisely because inconsistent intervals make SLA compliance in SD-WAN impossible to verify across vendors or time periods, according to MEF's performance monitoring specification.

In practice, most enterprise teams settle on a layered approach:

Voice and real-time traffic: short calculation intervals, often one to five minutes, because a voice SLA breach that lasts ten minutes is a full afternoon of dropped calls if nobody notices.
Transactional/interactive traffic: five to fifteen-minute calculation windows, balancing noise reduction against detection speed.
Bulk/best-effort traffic: hourly or even daily aggregation is usually fine, since nobody's paging the NOC over a slow overnight backup job.

The standard itself doesn't hand you a required tooling implementation, which is the gap that trips up teams migrating between vendors: MEF-105 tells you what a "calculation interval" means and that it must be agreed upon, but leaves the actual polling mechanism, BFD, TWAMP, or otherwise, entirely to the implementer.

That gap matters most during migrations. If you're comparing SD-WAN performance metrics against your legacy MPLS baseline, use identical calculation intervals and identical probe types on both sides of the comparison, or the "improvement" you report to leadership might just be a measurement artifact.

How Do You Build a Monitoring Architecture That Doesn't Cry Wolf?

Overlay monitoring, controller dashboards, application-layer probes, SD-WAN vendor APIs, tells you how the SD-WAN fabric itself believes it's performing. Underlay monitoring, SNMP counters, raw interface statistics, flow telemetry from routers and switches, tells you what's actually happening on the physical and logical links underneath that fabric. Relying on either one alone is how you end up chasing phantom incidents or missing real ones.

A useful monitoring stack pulls from several sources at once:

Controller/overlay APIs for tunnel-level SLA class status and application-aware routing decisions.
SNMP interface counters on both SD-WAN edges and any underlying access-circuit hardware.
Flow telemetry (NetFlow/IPFIX) to see which applications are actually consuming the bandwidth during a degradation event.
Application-layer real-user metrics (init-failure rate, TCP RTT) for the handful of SaaS apps that actually justify the instrumentation effort.

Combining overlay and underlay telemetry produces measurably fewer false positives than relying on controller probes alone, because a circuit-level counter can confirm whether a controller-reported SLA violation reflects a real physical-layer problem or a transient probe anomaly, according to DX NetOps's guidance on monitoring best practices. Palo Alto's Prisma SD-WAN takes this correlation further at the incident level, automatically suppressing duplicate child incidents when a single circuit-quality issue is generating both a network alert and an application alert, so the on-call engineer sees one root cause instead of five noisy tickets for the same event.

For dashboards, resist the urge to display every raw metric on a single pane. Build around a small number of scorecards: an SLA compliance percentage per tunnel and per site, a rolled-up health indicator (often modeled as the green/yellow/orange/red tiering DX NetOps recommends), and a trailing view of MIR utilization against provisioned capacity. Anything more granular belongs one click deeper, not on the main view.

Building the Operational Runbook: From Baseline to Remediation

Baselining is where most SD-WAN SLA monitoring efforts quietly fail, not because engineers skip it, but because they baseline against the wrong conditions. Capture at least two to four weeks of data before any migration, spanning normal business days, month-end processing spikes, and off-hours traffic, using the same probe type and calculation interval you'll use afterward. IP SLA operations or emulated real-user testing both work; what matters is consistency, so your pre-migration and post-migration numbers are actually comparable rather than an apples-to-oranges artifact of different measurement tools.

Alert tiers give your team a shared vocabulary for severity, and a four-tier model works well in practice:

Green: all SLA metrics within threshold. No action, log for trending only.
Yellow: one metric approaching threshold (within 80% to 100% of the limit) for a sustained window. Notify on-call, no paging.
Orange: one or more SLA class thresholds breached, with automated failover already engaged. Page on-call for confirmation and root-cause investigation.
Red: SLA breach with no compliant fallback path available. Immediate escalation, carrier engagement, and executive notification if customer-facing services are affected.

When a breach hits orange or red, work the problem in a fixed order rather than guessing:

Confirm the breach against a second data source (underlay counters, not just the controller dashboard) to rule out a probe-only anomaly.
Check whether automated steering already moved traffic to a compliant tunnel, and verify that move actually resolved the user-facing symptom.
Identify whether the degraded metric is latency, jitter, loss, or MIR, since each points to a different root cause category.
Pull flow telemetry for the affected window to see if a bandwidth-heavy application coincided with the breach.
If no internal fallback exists, open a ticket with the underlying carrier, citing your calculation interval and measured values so their NOC isn't starting from zero.
Document the remediation and the time-to-resolution against your SLA compliance scorecard for trend analysis.

Remediation options scale with severity. For transient jitter or loss, quality-of-service (QoS) queuing or forward error correction (FEC) on the SD-WAN edge can often absorb the problem without any human intervention. For sustained circuit degradation, carrier engagement is the right escalation path, and having the calculation-interval data ready shortens that conversation considerably. For anything that smells like a hardware fault, a failing transceiver, a flapping interface, check physical layer counters before assuming it's a software or routing issue. Our own SD-WAN failover runbook walks through the failover-specific piece of this in more depth, and general remediation techniques like QoS tuning get more coverage in our managed LAN/WAN performance guide.

Pro Tip: Keep a rolling 90-day archive of raw SLA metric data, not just the aggregated scorecard numbers. When a carrier disputes an SLA credit claim, aggregated averages are far less persuasive than the raw calculation-interval data showing exactly when and how long the breach lasted.

What Configuration Values Should You Actually Use?

Poll interval choice is a tradeoff between responsiveness and noise, not a single right answer. A 10-second poll interval catches problems fast but generates enough data volume and enough sensitivity to transient noise that you'll want a wider sliding window to compensate. A 300-second poll interval is quiet and stable but means a real outage could run five minutes before the controller even notices, which is unacceptable for voice traffic and perfectly fine for a bulk backup circuit.

Recomputation timers control how quickly a tunnel can be reclassified once its measured metrics change, and here the split by traffic type matters:

Voice/real-time tunnels: short recomputation timers, prioritizing fast reaction over stability, since a few seconds of bad audio is noticeable but a few minutes is a failed meeting.
Bulk/best-effort tunnels: longer recomputation timers, since flapping a bulk-traffic tunnel back and forth doesn't improve anything and just adds routing churn.

Probe selection per application class follows a similar logic. For voice, use whatever combination of BFD, TWAMP, and TCP-echo your platform supports, since voice tolerates the least uncertainty. For SaaS applications, application-layer probes measuring init-failure rate and real RTT tell you far more than a generic ICMP or BFD number ever will, because they capture the actual user experience path, DNS resolution, TLS handshake, and application response, not just network reachability.

A sensible policy pattern, expressed in plain terms rather than vendor-specific syntax, looks like this: classify voice traffic first against the tightest SLA class using BFD and TWAMP data with a short recomputation timer, classify transactional and interactive SaaS traffic second against a moderate SLA class using combined network and application-layer metrics, and let everything else fall through to a bulk/best-effort class with relaxed thresholds and long recomputation timers. Layering the policy this way means your tightest, most sensitive monitoring effort goes where it actually changes user experience.

How Does a Managed Provider Actually Run This in Practice?

Running SLA metrics for SD-WAN well at scale, across a dozen sites or more, stops being a configuration problem and becomes an operations problem. An approach centered on a proprietary platform can give engineers real-time observability into tunnel health, SLA class status, and circuit performance across multiple managed sites from a single dashboard rather than logging into numerous controllers.

When a threshold breach happens, the workflow runs through a 24/7 U.S.-based NOC rather than waiting for a customer to notice degraded call quality first. That NOC triages the alert against both overlay and underlay data before it ever reaches a customer-facing ticket, then routes confirmed incidents to a certified engineer, in some cases triple-CCIE certified staff, so the person responding actually understands the SLA class logic behind the alert rather than just restarting a device and hoping.

Carrier diversity plays a direct role in false-positive reduction. Sourcing connectivity from more than 50 carriers means a single provider's local network issue doesn't get mistaken for a systemic SD-WAN failure. That diversity, combined with managed probe deployment tuned per site and per application class, gives visibility that a single-carrier deployment structurally can't match. It's also the operational backbone behind California Telecom's 99.99% uptime SLA on data services, a number that only means something when the monitoring behind it is actually catching problems before customers do.

What Actually Trips Up Teams Instrumenting This for the First Time

The most common mistake I see is treating one measurement source as gospel. Teams trust the controller's SLA dashboard exclusively, and when a customer complains about call quality that the dashboard says is fine, they assume the customer is wrong. Usually the customer is right, and the probe traffic is being treated differently than production traffic somewhere in the path. Cross-check overlay against underlay every time.

The second mistake is copying vendor default thresholds without adjusting for your actual applications. A default voice SLA class tuned for generic VoIP may be too loose for a demanding video conferencing platform. Test against your real traffic, not the vendor's assumption of it.

The third: skipping the baseline. Without pre-migration numbers captured at the same calculation interval you'll use later, you can't prove SD-WAN improved anything, and you can't prove it didn't. If you're starting fresh, start there. Pick your four core metrics, agree on calculation intervals before you deploy, and instrument accordingly.

— Jim

Get Help Monitoring SLA Metrics Across Every Site

Building and tuning SLA monitoring in-house means someone on your team owns probe configuration, threshold tuning, and 2 AM pages when a tunnel drops out of compliance. California Telecom exists so that job doesn't fall entirely on your engineers. Through the Netverge platform, our clients get real-time SLA class visibility across every site on one dashboard, backed by a 24/7 U.S.-based NOC that triages breaches before they become tickets and a 99.99% uptime SLA on data services.Because we source connectivity from more than 50 carriers and design every deployment through our own engineers rather than a generic install crew, false-positive alerts drop and root-cause diagnosis speeds up, without a truck roll for every threshold breach. If you're running multi-site SD-WAN today and want SLA compliance data you can actually defend in a carrier dispute or a leadership review, start with our Managed SD-WAN page and request a network consultation to see what a baseline assessment looks like for your sites.

Sources

FAQ

Is SD-WAN Obsolete?

No. SD-WAN adoption keeps growing because it solves a problem MPLS alone never did: dynamic, application-aware traffic steering based on live SLA metrics rather than static routing. What's changing is sophistication, more granular SLA classes, tighter integration between network and application-layer telemetry, not relevance.

What Are the Four Main Components of SD-WAN?

Most architectures break down into an orchestration/controller layer, edge devices at each site, transport-agnostic overlay tunnels across whatever underlying circuits are available, and a centralized policy engine that applies SLA classes and security rules. The controller and policy engine are what actually consume your SLA metrics for SD-WAN to make steering decisions.

What Is the Performance SLA in Fortinet?

FortiGate's Performance SLA feature reports live latency, jitter, and packet loss for each configured link, using probes you define, ping, HTTP, DNS, and additional types available through CLI configuration, per Fortinet's monitoring documentation. Those measurements bind directly to SD-WAN rules, so a link failing its Performance SLA gets excluded from eligible paths for the traffic tied to that rule.

How Often Should SD-WAN SLA Metrics Be Measured and Reported?

It depends on traffic type: voice and real-time applications need calculation intervals of one to five minutes, while bulk traffic tolerates hourly or daily aggregation. MEF-105 requires that whatever interval you choose be explicitly agreed upon and consistently applied so reports stay comparable across time periods.

Do I Need a Managed Provider to Monitor SD-WAN SLA Metrics Properly?

Not strictly, but instrumenting probes, tuning thresholds, and staffing 24/7 response is a real operational lift for an in-house team. Providers like California Telecom handle this through a managed NOC and observability platform so your team isn't the one absorbing 2 AM SLA breach pages.

Predict Outages: 4 SD‑WAN SLA Metrics Network Engineers Must Monitor

Table of Contents