I’ve been testing SD-WAN with SLA monitoring on our FortiGate over regular internet connections (cable and fiber). The performance targets keep getting missed even when the links seem fine. Latency and packet loss thresholds trigger failovers when there’s no real user impact.
Is this a known issue? How do you make it reliable without dedicated MPLS? I’m trying to automate some SaaS failovers with webhooks, but if the monitoring itself is flaky, the automation falls apart.
Still learning.
The SLA monitoring on internet links is notoriously noisy because it's measuring the raw transport, not the actual application experience. You're seeing failovers for metrics that don't translate to user impact. That's expected behavior for these probes.
You need to tune your SLA targets to be less sensitive, or better yet, supplement them with synthetic application-layer checks. If you're automating failovers based purely on ICMP latency or loss across public internet, you'll have a bad time. I've seen teams add a simple HTTP GET to a critical SaaS endpoint's health check URL as a secondary condition before triggering a failover. It adds a necessary delay but prevents flapping.
Have you looked at the actual probe intervals and packet sizes? Sometimes the defaults are too aggressive for commodity broadband, causing the very congestion they're trying to detect.
FinOps first, hype last
You're right to question it. Those SLA probes are low-level and hyper-sensitive by design, and the internet is a best-effort network. Your automation is reacting to transport noise, not a real service problem.
I'd recommend pairing the SLA probe with an application-layer health check before you trigger any webhook. For critical SaaS failovers, we often set up a secondary monitor that pings the actual SaaS API endpoint. The SLA probe can flag a potential issue, but the failover only proceeds if the app check also fails. This adds a few seconds of delay but stops the flapping.
Have you tried adjusting the probe frequency and size? Sometimes just making it less aggressive - like one probe every 5 seconds instead of every second - can filter out the noise without losing real visibility.
Integrate or die
You're absolutely right to be skeptical. It's a common frustration. The core issue is you're letting an infrastructure-level probe make an application-level decision.
Those SLA probes are designed to be hyper-sensitive to packet loss and latency for the underlying transport. The internet is inherently noisy at that layer, but your users aren't experiencing loss at the TCP session level with their SaaS app. That's why you see the failover triggers when things seem fine.
Instead of trying to make the SLA monitoring more reliable, use it as a first alert. Let it flag a potential problem, but require a secondary, application-specific health check to confirm before any automation fires. For SaaS, that could be an HTTP GET to the service's health endpoint. It adds a slight delay but completely eliminates the flapping. Your webhook automation should only trigger when both conditions are met.
—daniel
Been there, done that. I've burned days tuning those exact FortiGate SLA probes. They're basically measuring network weather, not if the app is working.
The trick I found was adding a 15 second cooldown on any failover event. Even with sensitive thresholds, it stops the flapping. Also, try pointing the probe at a closer target, like your ISP's DNS instead of 8.8.8.8. Less internet hops means less noise.
For webhooks, can you add a quick ping to the SaaS login page as a sanity check? That filters out the false positives.
Demo or it didn't happen
Oh, that's such a classic pitfall. You've hit on the exact reason I stopped relying solely on those low-level probes for automation triggers. The SLA is measuring the highway's potholes, not whether your delivery truck actually arrived.
Your idea to use webhooks for SaaS failovers is great, but you're right - if the monitoring is flaky, you're automating chaos. What finally worked for me was treating the SD-WAN SLA as a "canary in the coal mine," not the fire alarm. I set it to trigger a secondary, application-aware script. That script does a quick curl to the actual SaaS API endpoint and checks for a valid JSON response before sending any failover webhook. It adds maybe 10 seconds of delay, but it completely eliminated the false positives.
Have you looked at the probe target? I found pinging my ISP's first hop was dramatically less noisy than pinging 8.8.8.8 across the whole public internet.
Test, measure, repeat