Heads-up: Palo Alto sys_metrics v3.0 breaks the stock Prisma SD-WAN Performance DataSource
Summary: David Bond reported that the new version 3.0 of the Prisma SD-WAN sys_metrics API introduced by Palo Alto on August 13, 2026, changes the DiskUsage and MemoryUsage metrics from percentage available to percentage used. This change has caused many devices to report incorrect disk and memory figures, impacting monitoring within LogicMonitor. David Bond provided a detailed analysis, suggesting several corrective actions, such as updating the monitoring modules to be version-aware and reconsidering the automatic adoption of new API versions. Michael Rodrigues acknowledged the issue and noted that they are coordinating with the relevant teams to address the problem and inform users.
TL;DR — On 13 August 2026 at approximately 19:00 UTC, Palo Alto published version 3.0 of the Prisma SD-WAN sys_metrics API, which intentionally changes DiskUsage and MemoryUsage from percentage available to percentage used. The stock LogicMonitor DataSource PaloAlto_Prisma_SDWAN_EdgePerformance computes 100 - value for these two metrics, and auto-selects the highest API version the controller advertises. The result is that every Prisma SD-WAN ION now reports inverted disk and memory figures, with no change on the customer's side.
We saw this across an estate of ~525 IONs: roughly 490 devices crossed the DiskUsed alert thresholds within about twenty minutes of each other. If you monitor Prisma SD-WAN with the out-of-the-box modules, you are almost certainly affected right now.
The symptom
DiskUsed steps to ~95–99% on every ION at once and stays there, tripping the stock > 95 98 99 thresholds. Cpu is unaffected.
Two devices, before and after (values from LogicMonitor's own graph data):
DeviceTime (UTC)CpuDiskUsedMemoryUsed A13 Aug 15:186.282.19546.30 A13 Aug 18:586.4097.80453.68 B13 Aug 15:138.291.90772.65 B13 Aug 19:177.9598.09327.18
The before and after values sum to exactly 100. These are complements, not a real change.
The part that matters more than the alert noise
MemoryUsed is inverted too, and it fails silently in the dangerous direction.
Device B above went from a true 72.7% memory used to a reported 27.2%. The disk inversion is loud and obvious — hundreds of alerts and, for anyone with ITSM integration, hundreds of incidents. The memory inversion is the opposite: a device under genuine memory pressure now reports plenty of headroom and will not alert. Anyone who has been running inverted since 13 August has had no working memory alerting on their SD-WAN edge estate, and nothing in the UI would tell them.
If you are affected, it is worth reviewing that window specifically, not just clearing the disk alerts.
Root cause — Palo Alto documents this themselves
This is an intentional, documented breaking change, not a Palo Alto bug, and it will not be reverted.
From Palo Alto's public OpenAPI specification (open_api_unified.json, also rendered on pan.dev), path /sdwan/monitor/v3.0/api/monitor/sys_metrics:
Behavior change in 3.0: DiskUsage and MemoryUsage report the percentage used; versions 2.0 – 2.4 reported the percentage available. CPUUsage min and max are corrected; earlier versions returned them swapped. Supported metrics are unchanged from 2.4.
The same change re-labelled the previous version. Path /sdwan/monitor/v2.4/api/monitor/sys_metrics:
Deprecated behaviour.
DiskUsageandMemoryUsagereport the percentage available, not used, andCPUUsagereturnsminandmaxswapped. Version 3.0 corrects all three.
Timing lines up exactly. The spec commit introducing v3.0 is dated 2026-08-14T06:02:17Z; the previous revision (2026-08-07) contains no v3.0 and no deprecation note. The API changed on the 13th and the documentation synced the following morning. The same commit applies the identical change to the legacy CloudGenix-style spec, so both API styles are affected.
Why it reached everyone with no configuration change
The stock collection script selects the highest API version the controller advertises:
The moment 3.0 appeared in the auto-discovered list — ours now reads 2.0,2.1,2.2,2.3,2.4,3.0 — every collector silently moved from v2.4 to v3.0, while the DataSource carried on applying the v2.4-era correction:
An inversion designed for "available" applied to a value that is now "used". That is the entire fault.
Scope — which modules are affected
We checked all four stock Prisma SD-WAN DataSources. Only one carries the inversion:
ModuleLocatorVersionUses sys_metrics?Has 100 - x? PaloAlto_Prisma_SDWAN_EdgePerformance2C69WT1.2.0YesYes — affected PaloAlto_Prisma_SDWAN_EdgeHealthFL44YM1.6.0NoNo PaloAlto_Prisma_SDWAN_UnderlayLN6GNG1.6.0NoNo PaloAlto_Prisma_SDWAN_OverlayCCP4941.3.0NoNo
The fix we applied, and how we verified it
We removed the inversion so the script emits the API value unchanged, keeping v3.0. A Poll Now immediately afterwards on device A returned:
Those land on the pre-13-August values to three decimal places. That is what makes this conclusive rather than merely plausible: removing the inversion restores continuity with the historic series and correct alerting, which is only possible if the API semantics were what Palo Alto says they are.
We do not recommend pinning back to v2.4 as a long-term answer. It is now formally deprecated, and Palo Alto deleted v2.3 from the spec in this very same commit — pinned versions here have a limited shelf life.
What we think LogicMonitor needs to do
Posting this openly because the fix belongs in the module, not in every customer's portal — and because affected customers are alerting right now.
1. Correct PaloAlto_Prisma_SDWAN_EdgePerformance (2C69WT). Ideally make the transformation version-aware rather than simply deleting it, since the correct behaviour genuinely differs by API version:
// invert only for the deprecated versions that report "available"
boolean reportsAvailable = (sysMetricsVersion in ["2.0","2.1","2.2","2.3","2.4"])
if (reportsAvailable && (dpName == "DiskUsage" || dpName == "MemoryUsage")) {
lmEmit.dp(dpName, dpAvg ? (100 - dpAvg) : 0)
} else {
lmEmit.dp(dpName, dpAvg)
}That keeps working for any customer still pinned to an older version, and is correct on v3.0.
2. Check the CPUUsage min/max correction. Palo Alto's note says v3.0 also fixes min and max being returned swapped. If the paloalto.prismasdwan snippet requests a min or max statistic, the meaning of Cpu has changed too. Our Cpu values moved only slightly, so we cannot tell from the outside — but you can, and the datapoint is described as "Maximum percent CPU utilization".
3. Fix the version-selection logic across all four Prisma modules. ?.split(",")?.max() is a string comparison, used at 11 call sites across the four DataSources. It is already wrong today, independently of this incident: auto.paloalto.prisma.sdwan.apiversion.waninterfaces currently advertises 2.1 … 2.9,2.10, and string-max returns "2.9", not "2.10". It needs a numeric version comparison.
4. Reconsider auto-adopting the maximum advertised version at all. Taking whatever the vendor publishes means a documented breaking change becomes a silent data-correctness incident in every customer portal simultaneously, at a time of the vendor's choosing. Pinning modules to a validated version, and treating a newly advertised version as something to review rather than adopt, would have contained this entirely.
5. Please proactively contact customers monitoring Prisma SD-WAN. This is the important one. Every customer using the stock module is affected, the disk alerting is noisy enough to be self-evident, but the memory under-reporting is silent and will not be noticed. Customers cannot reasonably be expected to discover this themselves — the numbers look plausible, nothing errors, and the module is behaving exactly as written.
A known-issue entry plus a targeted notification to Prisma SD-WAN customers would save a lot of people a confusing morning, and would close the memory-alerting gap before someone finds it the hard way.
Michael Rodrigues
·2 weeks ago · EditedThe fix for this has been shipped. You may not see it in the Exchange for a few more hours depending which pod your portal is on. New modules are same name, version 1.3.
We're working on specifically messaging impacted accounts as well.
Michael Rodrigues
·3 weeks agoThanks @David Bond , I've got a ticket into the ME team to fix and will reach out to the comms team to make sure users know about this.