/network-health-sweep

name: "Network Health Sweep"
description: >
  A normalized device and network health sweep across whatever
  network-monitoring tools (Auvik, Meraki, Domotz) are connected: each vendor
  family's data model and native status fields mapped into one
  Down/Degraded/Unknown/Healthy taxonomy, default interface error and
  utilization thresholds, topology-change detection, and why an offline
  Domotz collector renders its devices "unknown" rather than "down".
when_to_use: >-
  When running a portfolio-wide or single-client network health check across
  whatever network monitoring tools are connected. Use when: network health,
  network audit, device down, device offline, interface errors, interface
  utilization, topology change, network status review, is the network okay.

Network Health Sweep

Overview

"Is the network healthy" is a portfolio question, not a single-device question. This skill runs a normalized health check across every connected network-monitoring tool and rolls the result up into one ranked view — the same sweep a senior network engineer would run by hand across each vendor's console, made explicit, repeatable, and vendor-agnostic.

This is infrastructure-substrate health: is the network itself up, are interfaces clean, has the topology changed unexpectedly. It is not ticket triage (see `ops-pack`) and it is not application-layer reliability (see `devops-pack`, if connected) — this skill only answers whether the wires, switches, firewalls, and access points a client depends on are functioning.

Anti-triggers

• **One vendor's device, alert, or interface data** — use `auvik-devices`,

`auvik-alerts`, `meraki-devices`, or `domotz-devices` when the question is what that platform returns, rather than how to rank findings across all of them.

• **Hands-on diagnostics against a specific device** — ping, cable test,

throughput, and reboots are live tools, not a sweep; use `meraki-troubleshooting`.

• **Collector health as its own subject** — use `domotz-agents`; this skill

checks agent status only to decide whether "down" or "unknown" applies to the devices behind it.

Discovering available tools first

Because this pack is cross-vendor, never assume which network-monitoring tool is connected, or what its tools are literally named:

1. Call `conduit__search_tools` with a query like `"list devices"`, `"network health"`, or `"device status"` to discover which network-monitoring connector(s) are actually live for this org, and the exact tool names each exposes (they follow `<vendor-slug>__<tool_name>`, e.g. `auvik__devices_list`, `meraki__list_networks`, `domotz__list_agents`). 2. More than one network-monitoring tool can be connected at once (e.g. Auvik for one site, Meraki for another) — discovery may return multiple vendor families. Sweep all of them; do not stop at the first match. 3. Only after discovery, call the concrete tools that came back. Never speculatively call a tool name that discovery didn't return — an unrecognized tool call is a worse failure mode than reporting "no network monitoring connector found."

Key Concepts

Each vendor family's data model, and how they normalize

| Concern | Auvik | Meraki | Domotz | |---|---|---|---| | Unit of "connected" | Tenant → Network → Device → Interface | Organization → Network → Device | Agent (collector) → Network → Device | | Device-down signal | Device status field (`online`/`offline`/`warning`) via `auvik__devices_list` / `auvik__devices_get_details` | Device status via Meraki's device/network status tools | Device status per agent, reported by the local Domotz collector | | Interface/link health | Per-interface stats (errors, discards, utilization) via `auvik__interfaces_list` / `auvik__statistics_interface` | Per-port/uplink stats surfaced at the network/device level | Interface-level detail is thinner — Domotz is stronger on device reachability than deep interface counters | | Topology-change detection | Auvik's core differentiator — topology/config diffs surfaced via configuration and audit history tools (`auvik__configurations_list`, `auvik__entities_list_audits`) | Not a first-class primitive — infer from device/network membership changes between sweeps | Agent-scoped network scans can surface new/missing devices between runs | | Collection unit that can itself be "down" | N/A — cloud-polled via SNMP/API | N/A — cloud-managed dashboard | The agent itself — if the collector host is offline, every device behind it reads as unknown, not necessarily down. Always check agent status first. |

Normalize every vendor's native status into one shared health taxonomy before combining results:

• **Down** — device confirmed offline/unreachable.
• **Degraded** — device online but showing interface errors, high utilization,

or a warning-level status.

• **Unknown** — the collector/agent responsible for that device can't be

confirmed healthy itself (this matters most for Domotz — an offline agent means "unknown," not "down," for everything behind it).

• **Healthy** — no findings.

Interface errors and utilization thresholds

In the absence of a documented client-specific threshold, use these as defaults and state clearly that they're defaults, not tuned policy:

• **Utilization** — sustained (not momentary) utilization above 80% on an

uplink or trunk interface is a capacity/degradation flag; above 90% is urgent.

• **Errors/discards** — any non-zero, climbing error or discard counter on an

interface across two consecutive sweeps is a degraded-link flag. A single static, non-climbing count is likely historical and lower priority.

Topology-change detection

A topology change (new device joins, a device disappears, an uplink moves) is not automatically bad — but it's a signal that deserves a callout, because unplanned topology changes are how MSPs miss rogue devices or a client's in-house change that wasn't communicated. Where the connected tool expo