Hardware Health - Thresholds & Alerting in the SolarWinds Platform Explained

This article explains how Hardware Health monitoring works in the SolarWinds Platform, and clarifies the difference between hardware health thresholds (visual status indicators) and alerts (notifications and actions). These two concepts are frequently confused but operate independently of each other.

How Hardware Health Polling Works

The SolarWinds Platform monitors hardware health by polling vendor-specific sensors on your devices using SNMP, WMI, or CIM. Polling is enabled by default when a node is added. You do not define what to poll; The platform polls what the device exposes.

Supported vendors and devices (SolarWinds Platform 2026.2)

• Arista 7500E chassis

• Aruba

• Check Point

• Cisco (including modular chassis hardware — see What's new in 2026.2)

• Cisco IronPort

• Dell – PowerEdge

• Extreme Networks (new in 2026.2 — see What's new in 2026.2)

• F5

• Fortinet / FortiSwitch

• HP / HPE – ProLiant

• IBM – xSeries (legacy; verify current support with agent software)

• Juniper

• Nutanix (via SAM)

• VMware

• Cisco UCS (via SAM)

Note: The SolarWinds Platform does not support hardware health monitoring for Meraki organizations, because they do not expose hardware health information via SNMP or API.

For Dell, HP/HPE ProLiant, and IBM devices, SAM requires third-party hardware monitoring agent software (such as Dell OpenManage or HP ProLiant Management Pack) to be installed on the monitored server before hardware health data is available.

Monitored sensors

• Fan status

• Power supply status

• Temperature

• Disk status

• Battery status

• Array controller status

• Physical memory status

• Chassis intrusion status

• CPU temperature and/or status

Sensor availability depends on what the device and its agent software expose.

Part 1: Hardware Health Thresholds

Thresholds are visual status indicators in the SolarWinds Platform web console. They control whether a sensor is displayed as:

• Green — Up / normal

• Yellow — Warning

• Red — Critical

Key point: Thresholds are used only for the visual display in the web console (charts, gauges, summary views, maps). They have no effect on alerting. An alert fires based on trigger conditions you define—not on threshold values.

Hardware health threshold sources

Hardware health thresholds are determined in the following order of precedence:

1. Vendor/device defaults — The hardware monitoring agent software pre-programs thresholds at the device level. The SolarWinds Platform reads the status the device reports and displays it. This is the default behavior.

2. SolarWinds Platform custom thresholds — You can override vendor thresholds on a per-sensor basis in the platform web console. Available since SolarWinds Platform 2015.

Managing hardware health thresholds

To manage thresholds for individual sensors:

1. Go to Settings > All Settings > Node & Group Management > Manage Hardware Sensors.

2. Select the sensor you want to edit, and click Edit Thresholds.

   • To locate all sensors on a specific node, select Node in the Group By list, then select the node.

3. Choose how the sensor status should be determined:

   • Use Orion Defaults — Uses thresholds configured on the device (default).

   • Force to Up — The sensor always displays as Up, regardless of the actual value. Use this if a sensor is known to be noisy or not relevant.

   • Set Custom Thresholds — Define your own status rules using the dynamic query builder.

4. Click Submit.

Custom threshold data is stored in the database table APM_HardwareItem_Thresholds.

Changing temperature display units

Temperature display (Fahrenheit vs. Celsius) is a per-user setting:

1. Go to Settings > Manage Accounts.

2. Select your account and click Edit.

3. Under Server & Application Monitor Settings, change your temperature display preference.

Changing the Cisco MIB used for polling

The SolarWinds Platform can poll Cisco devices using either CISCO-ENTITY-SENSOR-MIB or CISCO-ENVMON-MIB. If values appear inconsistent with what the device reports, switching the MIB can resolve the issue.

To change globally: Go to Settings > All Settings > Polling Settings > scroll to Hardware Health Polling > select the preferred MIB from the Preferred Cisco MIB drop-down.

To change for a single node: Go to Settings > Manage Nodes > select the node > Edit Properties > scroll to Hardware Health Polling > change Preferred Cisco MIB > click Submit.

Part 2: Hardware Health Alerting

Alerts in the SolarWinds Platform are completely independent of threshold settings. An alert fires when the trigger conditions you define are met in the Alert Manager—not when a threshold changes color.

Default alert

There is a built-in alert: "Alert me when a Hardware Component goes into Critical or Warning state". This alert triggers on any hardware sensor that enters a critical or warning status as reported by the device.

Customizing the alert message

To include the sensor name, node, and status in the alert email, use the following variables in your alert message body:

${SensorDisplayName} on ${NodeName} is ${SensorOrionStatus} with the following issue: ${SensorOrionStatusDescription}

Creating a temperature-specific alert

To alert only when a temperature sensor exceeds a specific value, edit the alert's trigger conditions and add:

• APM Hardware Type Name is equal to Temperature

• APM Hardware Sensor Value is greater than [your threshold value]

You can also scope alerts to specific groups of nodes using Groups or Custom Properties, and then filter the alert to that group or property.

Querying hardware health data in the database

For troubleshooting or reporting, hardware health data is stored in the following tables:

-- Scripts are not supported under any SolarWinds support program or service.
-- Scripts are provided AS IS without warranty of any kind. SolarWinds further
-- disclaims all warranties including, without limitation, any implied warranties
-- of merchantability or of fitness for a particular purpose. The risk arising
-- out of the use or performance of the scripts and documentation stays with you.
-- In no event shall SolarWinds or anyone else involved in the creation,
-- production, or delivery of the scripts be liable for any damages whatsoever
-- (including, without limitation, damages for loss of business profits, business
-- interruption, loss of business information, or other pecuniary loss) arising
-- out of the use of or inability to use the scripts or documentation.

SELECT TOP 1000 * FROM [dbo].[APM_HardwareItem]
SELECT TOP 1000 * FROM [dbo].[APM_HardwareInfo]
SELECT TOP 1000 * FROM [dbo].[APM_HardwareCategory]
SELECT TOP 1000 * FROM [dbo].[APM_HardwareCategoryStatus]
SELECT TOP 1000 * FROM [dbo].[APM_HardwareItem_Thresholds]

What's New in 2026.2

Cisco modular hardware health

SolarWinds Platform 2026.2 adds visibility into Cisco modular chassis components, including line cards, power supplies, and fan trays. Data collected includes reset reasons and last status change times, sourced from CISCO-ENTITY-FRU-CONTROL-MIB (tables: CiscoFRUModuleStatusTable, CiscoFRUNotificationSettings, CiscoFRUPowerStatusTable).

Important — Cisco FRU Warning sensors after upgrade: After upgrading to 2026.2, Cisco chassis devices (such as Catalyst 9300/9400/9500/9600, Nexus 7000/9000, ASR/ISR platforms) may show new hardware health sensors in a Warning state:

• FRU Status Change Notifications

• Power Supply Output Change Notifications

This behavior is by design. These sensors reflect whether SNMP trap notifications are enabled or disabled on the device — most Cisco devices have them disabled by default (value = 2), which the platform displays as Warning. They do not indicate an actual hardware fault.

To resolve: Go to Settings > All Settings > Node & Group Management > Manage Hardware Sensors, search for the affected sensors, select them, and click Disable. For large environments, use the advanced setting HardwareHealth.Data.HardwareHealth.IgnoredEventTypes.

See: Cisco Hardware Health Sensors Show Warning State After Upgrading to OSH/NPM 2026.2

Extreme Networks switch monitoring

2026.2 extends hardware health monitoring to Extreme Networks switches, adding a vendor-specific hardware health poller for chassis temperature, fans, and power supply status on supported Extreme models.

Improved sensor visibility for unreachable devices

Hardware health sensors are now preserved when a device cannot be reached for polling. Previously, if a node was unreachable, all sensor data disappeared from views, alerts, and reports. As of 2026.2, sensors remain visible with a status of Unknown instead of being removed.

A new advanced setting controls this behavior: HardwareHealth.Pollers.HardwareHealth.SNMP.NPM.MaxSnmpTimeouts (default: 3 timeouts before polling is considered failed).

HP ProLiant polling fix

A known issue that caused hardware health polling failures for HP ProLiant servers with the error "Can't get object from reader for class 'CIM_Chassis'" has been resolved in 2026.2.