FortiAP access points show 100% availability in HistoricalAccessPoints while AP status is Down

• Symptom

  • FortiAPs are reported Offline/Down in FortiManager.
  • In SolarWinds, n.AccessPoints.Status / StatusName = Down for the same FortiAPs.
  • At the same timestamps, Orion.Nodes.AccessPoints.HistoricalAccessPoints.Available = 1 and AvailablePercent = 100 for those APs.
  • SWQL-based alerts and SLA reports built on HistoricalAccessPoints.Available / AvailablePercent always show 100% availability and do not reflect outages.

• No UI error message

  • There is no pop-up or UI error. The issue is a data discrepancy between real-time AP status and wireless historical availability metrics.

• Impact

  • AP availability SLAs based on HistoricalAccessPoints are overstated (false 100%).
  • Alerts that depend on Available / AvailablePercent for FortiAPs may not trigger during real outages.
  • Customers requiring rules like “AP down for 3 consecutive minutes” cannot rely on HistoricalAccessPoints to implement them.

• What this article explains

  • Why FortiAPs can show Status = Down while HistoricalAccessPoints.Available/AvailablePercent remain 1 / 100.
  • That this is a product limitation in wireless historical data for FortiAPs, not a configuration problem.
  • Workaround options for alerting and SLA reporting that do not depend on these unreliable historical fields.

• Orion.Packages.Wireless.HistoricalAccessPoints is designed as a statistical history dataset (traffic, clients, availability percentages) and does not maintain a dedicated, authoritative AP status history column.
• For FortiAPs, the fields:
  • Orion.Nodes.AccessPoints.HistoricalAccessPoints.Available
  • Orion.Nodes.AccessPoints.HistoricalAccessPoints.AvailablePercent
    are controller-derived / aggregated metrics, not per-poll AP status.
• As a result, these fields can remain 1 / 100 even when:
  • The AP’s operational state in SolarWinds (n.AccessPoints.Status / StatusName) is Down, and
  • The controller (FortiManager) reports the AP as Offline.
• There is currently no dedicated AP status history entity that supports rules like “AP down for 3 consecutive minutes, de-duplicated per controller.”

There is no configuration change that makes HistoricalAccessPoints.Available / AvailablePercent a reliable FortiAP status history. Use the following supported workarounds instead:

1. Real-time alerting with 3-minute rule (use AP status, not HistoricalAccessPoints)

1. Create a custom alert on Access Points that triggers when:
   • n.AccessPoints.Status <> 1 (or StatusName <> 'Up') and
   • The corresponding controller node (Orion.Nodes) is Up.
2. In the alert evaluation settings, configure:
   • Trigger when the condition exists for more than 3 minutes (evaluation every 1 minute).

Result

• Satisfies the SLA rule “AP down for 3 consecutive minutes”.
• Suppresses alerts when the controller is down.
• Completely avoids reliance on HistoricalAccessPoints.Available/AvailablePercent.

You can further scope the alert so that it rolls up per controller (for example, one alert per controller node when one or more APs under it are in a sustained Down state).

2. SLA reporting using data that has real status/availability history

Depending on contractual requirements, use one of these approaches instead of HistoricalAccessPoints.Available/AvailablePercent:

a) Per-AP node availability

• Add each FortiAP as a managed node (ICMP-only or SNMP if supported).
• Calculate SLA using standard node availability from:
  • Orion.ResponseTime and/or
  • Orion.NodeStatusHistory.

This produces an SLA based on true polling availability rather than wireless history.

b) Alert-based SLA (if using the 3-minute status-based alert)

• If you implement the status-based AP alert in step 1:
  • Use Orion.AlertHistoryView / Orion.AlertStatus to sum the duration of “AP down (3-minute rule met)” alerts per AP or per controller over the reporting window.
  • Compute availability as:
    Availability = 1 − (total alert duration / total time in period).

This aligns directly with the customer’s SLA definition (breach after 3 consecutive minutes down).

c) Custom status logging (advanced / last resort)

• Use a scheduled job (SQL Agent, external script, or scheduled SWQL consumer) to:
  • Poll Orion.Nodes n JOIN n.AccessPoints ap and record ap.Status, controller status, and timestamp into a custom table every minute.
• Build SLA reports against that custom table (for example, count intervals where AP is Down vs total intervals), instead of using HistoricalAccessPoints.