I've been conducting a performance baseline analysis of our FortiSASE deployment for the last quarter, with a particular focus on latency as a key service-level indicator. My methodology involves synthetic probes from multiple client endpoints (FortiClients) to our internal applications, alongside continuous real-user monitoring (RUM) data collected via lightweight scripts on the actual user workstations. The discrepancy I am observing between the latency values reported in the FortiSASE admin portal (under Analytics & Insights > Performance) and the ground-truth measurements gathered directly from the endpoints is not just statistically significant—it is operationally misleading.
To illustrate, here is a representative sample from a single user session connecting to a SaaS application over a week, measured in milliseconds:
| Measurement Source | App: CRM (Avg RTT) | App: ERP (Avg RTT) | Internal Web Portal (Avg RTT) |
|--------------------|---------------------|---------------------|-------------------------------|
| FortiSASE Dashboard | 34 ms | 41 ms | 22 ms |
| Endpoint ICMP Probe | 89 ms | 102 ms | 67 ms |
| Endpoint TCP Handshake | 112 ms | 125 ms | 81 ms |
The dashboard consistently reports latency figures that appear to be measuring only the segment from the FortiSASE PoP to the application server, completely omitting the critical "first mile" from the user endpoint to the FortiSASE edge. This is a profound oversight for a service marketed on providing secure access from anywhere. The performance metric becomes meaningless if it excludes the most variable and potentially degraded portion of the path.
My hypothesis on the measurement methodology:
* The FortiSASE "Performance" latency metrics are likely derived from the FortiGate instances within the cloud PoPs, measuring the TCP handshake or application-layer request time from their egress point.
* This inherently excludes:
* The client-to-PoP tunnel establishment time (DTLS/TLS).
* The latency from the user's physical location to the nearest PoP, which can be substantial depending on ISP routing and last-mile congestion.
* Any packet processing delay on the client itself.
Has anyone else performed rigorous, independent verification of these metrics and encountered similar disparities? More importantly, has anyone discovered a configuration flag or a hidden analytics view that provides a more holistic measurement, perhaps one that includes the client-to-edge component? I am currently forced to maintain a separate monitoring stack (using a combination of `traceroute`, `tcpping`, and custom scripts) to obtain true end-to-end latency figures for our service level agreements, which negates a core value proposition of the integrated dashboard.
Furthermore, I am interested in whether these reported figures influence FortiSASE's own PoP selection logic for clients. If the system's internal performance view is myopic, it could be making sub-optimal routing decisions based on incomplete data.