NetMonHub

SWQL: Nodes Down in the Last 24 Hours

By NetMon Hub Editorial ·

SWQL For SolarWinds Platform (Orion): Network Monitoring Overview · Validated on SolarWinds Platform 2026.2.1 (as of July 2026)

What this query does

The query below pulls every managed node whose Status is 1 (Down) and whose status changed to that state within the last 24 hours. That second condition matters: without it you get a full list of every node stuck in a down state regardless of when it fell over — useful sometimes, but noisy when you want a “new outages today” view.

SELECT
    n.NodeID,
    n.Caption                   AS NodeName,
    n.IPAddress,
    n.StatusDescription,
    n.StatusLED,
    n.StatusOrLeafObject,
    n.LastSystemUpTimePollUtc,
    n.UnManaged,
    n.UnManageFrom,
    n.UnManageUntil,
    n.MachineType,
    n.Vendor,
    n.Location,
    n.Contact,
    n.StatusChangedTime
FROM Orion.Nodes n
WHERE
    n.Status = 1                                         -- 1 = Down in Orion's status enum
    AND n.StatusChangedTime >= ADDDAY(-1, GETUTCDATE())  -- last 24 hours (UTC)
    AND n.UnManaged = FALSE                              -- exclude intentionally suppressed nodes
ORDER BY n.StatusChangedTime DESC

Column-by-column rationale

ColumnWhy it’s here
StatusInteger enum. 1 = Down, 2 = Warning, 3 = Unknown, 9 = Unmanaged. Filter on 1.
StatusDescriptionHuman-readable string Orion builds from Status — e.g. "Node is down." Useful in alert messages.
StatusChangedTimeThe timestamp Orion last recorded a status transition. This is the correct field for a “went down in the last N hours” filter. It is stored in UTC.
LastSystemUpTimePollUtcThe most recent successful SNMP sysUpTime poll — handy for estimating actual downtime, but not a reliable filter column because it stops updating when the node stops responding.
UnManagedBoolean. TRUE means polling is suppressed. Excluding these avoids alert noise from maintenance windows.
StatusLEDShort LED-state string ("Down", "Up", etc.) — useful if your report renderer wants a colour cue.

Note: GETUTCDATE() returns the Orion server’s UTC clock. If your polling engine runs in a non-UTC timezone you may see a fixed offset between StatusChangedTime values and wall-clock time in your local UI. The query is still correct — just account for the offset when interpreting results.

The time filter in detail

n.StatusChangedTime >= ADDDAY(-1, GETUTCDATE())

ADDDAY(n, date) is a SWQL built-in that shifts date by n days; negative values go backwards. GETUTCDATE() returns the current UTC timestamp. Together they produce a rolling 24-hour window anchored to now, re-evaluated each time the query runs. You can swap in ADDHOUR(-6, GETUTCDATE()) for a tighter window or ADDDAY(-7, GETUTCDATE()) for a week.

There is no StatusChangedTime index that Orion exposes to SWQL, so on large environments (10 000+ nodes) expect a full table scan. If query latency is a concern, narrow the result set first with a site/group filter (see the variation below) before adding the time predicate.

Useful variations

Scope to a custom property or group

If your estate is segmented by a custom node property — say Region — add:

AND n.CustomProperties.Region = 'EMEA'

Custom properties hang off Orion.Nodes as a child entity and are accessible with dot notation. No JOIN needed.

Return only nodes that are still down right now

The base query catches nodes whose status changed in the last 24 hours; a node that flapped and recovered still appears. If you want only currently-down nodes that also transitioned within the window, the Status = 1 condition already handles this — the two predicates combined give you “went down in the last 24 hours AND is still down”. No extra clause needed.

Count by vendor for a dashboard tile

SELECT n.Vendor, COUNT(n.NodeID) AS DownCount
FROM Orion.Nodes n
WHERE
    n.Status = 1
    AND n.StatusChangedTime >= ADDDAY(-1, GETUTCDATE())
    AND n.UnManaged = FALSE
GROUP BY n.Vendor
ORDER BY DownCount DESC

Wiring this into an Orion alert

Orion alerts use the same SWQL engine under the hood. The trigger condition references Orion.Nodes directly; the query above translates cleanly into the alert wizard’s “I want to alert on” → Nodes → Advanced SQL path.

Step-by-step (Orion web console):

  1. Alerts & Activity → Manage Alerts → Add New Alert
  2. Set I want to alert on: Node
  3. Under Trigger Condition, choose Advanced SQL Condition and paste:
Status = 1
AND StatusChangedTime >= ADDDAY(-1, GETUTCDATE())
AND UnManaged = FALSE

Note: inside the alert condition editor, column references are unqualified (no n. alias).

  1. Set Re-trigger: Do not re-trigger (prevents repeated pages for a node stuck down across multiple evaluation cycles, unless you specifically want that).
  2. In Reset Condition, use:
Status != 1
  1. Build your alert message using ${NodeName}, ${StatusDescription}, and ${StatusChangedTime} variable substitutions — Orion resolves these from the triggering node row automatically.

Note: The 24-hour window in an alert trigger means Orion will fire the alert for a node that went down 23 hours ago if the alert has never fired before (e.g. after a monitoring restart). To avoid spurious pages after a planned maintenance window, pair this with an Acknowledged condition or use Maintenance Mode on affected nodes before the window starts.

Testing the query outside an alert

Use Orion Query Tool (buried under Settings → Query) or the SWQL Studio standalone client from the OrionSDK. Paste the full query, hit Execute, and inspect the result set before committing it to an alert.

For SWQL Studio: connect to https://<orion-hostname>:17778/SolarWinds/InformationService/v3/Json with an Orion admin account. The v3 JSON endpoint supports ADDDAY and GETUTCDATE() without any additional configuration.

Known limitations

Sources