FortiGate · FortiOS 7.4

FortiGate SD-WAN diagnostic commands for members, SLA and rules

Quick answer #

Inspect SD-WAN in three views: the members that exist, the measured health of their paths, and the members selected by a rule. A healthy WAN link is not automatically the chosen path for every application.

Scope: FortiOS 7.4 family. Use service4/service6 from 7.4.4 onward; earlier 7.4 builds use service. Run in the traffic VDOM.

Check members and measurements #

Check members and measurements
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Read-only
diagnose sys sdwan member
Read-only
diagnose sys sdwan health-check

Match member sequence numbers to interface names before interpreting the rest of the output. Read packet loss, latency and jitter against the relevant configured check and SLA, not as universal health scores. A probe answers a question about its own destination and protocol. It cannot prove that every SaaS endpoint beyond that link is healthy.

If several checks exist, isolate the one attached to the affected rule:

Check members and measurements
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Read-only

Replace these example values: <HEALTH_CHECK_NAME>.

diagnose sys sdwan health-check <HEALTH_CHECK_NAME>

Replace the placeholder with the existing name. Capture a second sample while the problem occurs. A single healthy sample taken after recovery cannot explain what the rule observed during the incident.

Check rule selection using the correct version #

For FortiOS 7.4.4 and later in the 7.4 branch:

Check rule selection using the correct version
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Read-only
diagnose sys sdwan service4
Read-only
diagnose sys sdwan service6

For 7.4.0–7.4.3, use the earlier command:

Check rule selection using the correct version
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Read-only
diagnose sys sdwan service

Do not run all variants as a blind sequence. The version distinction is why an otherwise familiar command can fail after an upgrade. service4 and service6 separate IPv4 and IPv6 rule status.

Interpret selection in context #

Locate the intended rule and its selected members, then compare its strategy with the measured conditions. More than one selected member can be valid for the rule's mode. The rule display is a decision view, while a specific user's existing session supplies the evidence of which path that connection actually uses.

When the selected path appears wrong, verify the original client source, destination, ingress interface and service. A rule you expected to match may not own that traffic. Policy-route lookup and a filtered session entry provide a practical cross-check before any preference or SLA threshold is changed.

Finish with an application observation #

Record the rule ID, selected member, health-check name, timestamp and one test flow together. This produces a useful comparison between intended policy, measured path quality and actual forwarding. Avoid resetting SD-WAN or disabling members as a diagnostic shortcut; those actions alter traffic steering for users beyond the test case.

Sources

Documentation reviewed: 8 October 2026