How to configure alerts for “polling is failing” node status (IsPollingError) in SolarWinds Platform 2026.1

2/12/2026 10:49 PM

2/13/2026 10:05 PM

Starting in SolarWinds Platform 2026.1, node status can change to Critical or Misconfigured when SNMP, WMI, or WinRM polling fails repeatedly while ICMP (ping) is still working.

Typical examples:

• Node status is Critical, SNMP polling is failing: 'Request timed out - possible causes include network issues, incorrect community string or SNMPv3 credentials, or device not responding.'
• Node status is Misconfigured, Wmi polling is failing: 'The user name or password is incorrect.'

Internally, SolarWinds:

• Tracks active polling errors and marks affected nodes with IsPollingError = TRUE.
• Forces node status to Critical (14) or Misconfigured (16) after a configurable period of continuous errors (default ~10 minutes), even though the node can still respond to ping.

To support this behavior, SolarWinds Platform 2026.1 includes a new out‑of‑the‑box alert:

• Alert name: Node polling failing
• Description:
  > This alert is triggered when statistics polling using SNMP, WMI, or WinRM fails, even though the node is still reachable via ICMP. This usually points to a configuration issue – most commonly incorrect credentials.
• Default trigger condition (Node):
• Node Is Polling Error is equal to Yes
• AND Node Status is equal to Critical

This OOTB alert is designed to notify you when polling is failing while the node is still reachable. However, many customers also have existing generic “Node is Critical” alerts. Without adjustments, both alerts can fire for the same node, causing duplicate alerts and confusion.

This KB shows how to:

• Clone and customize the OOTB “Node polling failing” alert (including recommended variables).
• Adjust existing node‑status alerts so they either:
• Exclude polling‑issue nodes, or
• Treat them differently from true node‑down events.

Hybrid Cloud Observability

This is not a bug in the alert engine. Instead:

• The new status behavior in 2026.1 exposes existing SNMP/WMI/WinRM problems that were previously silent.
• Existing status‑based alerts (for example, Status = Critical) now see more nodes in those states because node status incorporates polling‑error information.
• The new OOTB “Node polling failing” alert uses the IsPollingError flag. If you also have generic “Node is Critical” alerts, both may fire for the same node unless you choose to separate their scopes.

Without an alert strategy tuned for this feature, customers may:

• Receive a large number of Critical alerts immediately after upgrade.
• Not understand that “polling is failing” ≠ device down, but rather “device is reachable, but monitoring configuration/credentials/network needs attention.”
• See duplicate Critical alerts for the same node (one from the OOTB “Node polling failing” alert, plus one from an existing “Node is Critical” alert).

A. Use and customize the OOTB “Node polling failing” alert

Instead of creating a brand‑new alert from scratch, the recommended approach is to:

1. Review the built‑in Node polling failing alert.
2. Clone it and customize the clone to fit your environment (scope, recipients, message body).

A.1 Review the built‑in alert

1. In the web console, go to Settings > All Settings > Manage Alerts.
2. Locate the alert named Node polling failing.
3. Open it and note the default **trigger condition** (Node):
• Node Is Polling Error is equal to Yes
• AND Node Status is equal to Critical

This matches the intended design: polling is failing, node is still reachable by ping, status is now Critical.

A.2 Clone and rename the alert

To keep the original OOTB alert available, clone it:

1. From the Manage Alerts page, select Node polling failing.
2. Click Duplicate & Edit.
3. Rename the copy to something descriptive, for example:
• “Node has polling issues (SNMP/WMI/WinRM)”
4. Optionally add a description, such as:
• “Alert when a node is Critical due to SNMP/WMI/WinRM polling errors (IsPollingError = True). Device is reachable via ping but monitoring is not working correctly.”

A.3 Confirm or refine the trigger condition

On the cloned alert:

• Keep the basic conditions:
• Node Is Polling Error is equal to Yes
• AND Node Status is equal to Critical
• Optionally refine the scope:
• Limit to certain Environment / Site / Region custom properties.
• Exclude lab or non‑production nodes if desired.

This cloned alert now acts as your dedicated polling‑issues alert.

A.4 Recommended variables for the trigger action (email body)

Edit the Trigger Actions for the cloned alert and include variables that explain which node is affected and what the polling issue is:

Recommended variables:

NodeName: ${N=SwisEntity;M=DisplayName}
NodeIPAddress: ${N=SwisEntity;M=IP_Address}
NodeStatus: ${N=SwisEntity;M=Status}
Polled (ICMP) Status: ${N=SwisEntity;M=PolledStatus}
Error Description: ${N=SwisEntity;M=StatusDescription}
PollingErrorFlag: ${N=SwisEntity;M=IsPollingError}

Example email subject and body:

Subject:

[Polling issue] ${N=SwisEntity;M=DisplayName} – ${N=SwisEntity;M=StatusDescription}



Body:

Node: ${N=SwisEntity;M=DisplayName}
IP: ${N=SwisEntity;M=IP_Address}

Current node status: ${N=SwisEntity;M=Status} – ${N=SwisEntity;M=StatusDescription}
Polled (ICMP) status: ${N=SwisEntity;M=PolledStatus}
Polling error flag: ${N=SwisEntity;M=IsPollingError}


This node is reachable by ping but has persistent SNMP/WMI/WinRM polling issues.

Review credentials, SNMP/WMI/WinRM configuration, and network access between the polling engine and the node.

Optionally add:

• Web console link to node details:
  Node details: 

  ${N=SwisEntity;M=DetailsUrl}

• Any key custom properties:
  

  Environment: ${N=SwisEntity;M=CustomProperties.Environment}
  Site: ${N=SwisEntity;M=CustomProperties.Site}
  Owner: ${N=SwisEntity;M=CustomProperties.Owner}

A.5 Reset condition

Set the Reset Condition so the alert auto‑resolves when polling recovers. For example:

• Node Is Polling Error is equal to No
  OR
• Node Status is equal to Up

This ensures the alert clears once polling succeeds and the node is no longer in a polling‑error Critical state.

 

B. Adjust existing node‑status alerts to reduce noise and duplicates

Many environments already have alerts such as:

• “Node is Down”
• “Node is Critical”
• “Node is Warning or Critical”

With 2026.1 and the new polling‑issues behavior:

• These existing alerts may now trigger for nodes that are Critical due to polling errors, in addition to the Node polling failing / cloned alert.
• If your intention is for generic node‑status alerts to focus on true outages or threshold‑based critical conditions, you should explicitly exclude nodes where “Node Is Polling Error = Yes.”

B.1 Exclude polling‑issue nodes from generic Critical alerts

For each existing generic node‑status alert (for example, “Node is Critical”):

1. Open the alert in Manage Alerts.
2. In the **Trigger Condition**, add an **additional clause**:
• Node Is Polling Error is equal to No
3. Keep your existing status/threshold logic, for example:
• Node Status is equal to Critical
• AND Node Is Polling Error is equal to No

This keeps the generic alert focused on:

• Real down/unreachable nodes (where ICMP is failing), and/or
• Other status/threshold‑based Critical conditions that are not driven by the polling‑error feature.

The polling‑issues conditions will then be handled only by:

• The OOTB Node polling failing alert, or
• Your cloned/customized version of that alert.

B.2 Different actions for different alert types (recommended)

To avoid alert fatigue and clarify severity:

• For true node‑down alerts (for example, Status = Down or Unreachable):
• Use higher‑urgency actions such as paging/on‑call notifications.
• For polling‑issue alerts (IsPollingError = Yes, Critical status due to SNMP/WMI/WinRM failures):
• Use lower‑urgency actions, such as email or ticket creation, and route to the team responsible for credentials/config/network.

This separation helps teams understand the difference between:

• “Node is Down” – the device is not responding to ping and likely unavailable.
• “Node has polling issues” – the device is reachable, but monitoring via SNMP/WMI/WinRM is not working correctly and needs configuration or connectivity fixes.

By:

• Using the out‑of‑the‑box “Node polling failing” alert (or a clone),
• Adding the recommended variables to clearly show the cause of the polling issue, and
• Updating existing node‑status alerts to exclude polling‑issue nodes (Node Is Polling Error = No),

customers can avoid duplicate alerts, clearly separate device‑down vs polling‑failing scenarios, and respond more effectively to node status changes introduced in SolarWinds Platform 2026.1.