24 acceptance tests · 9 fields · Public CSV · No signup
RMM network device monitoring checklist
Prove that network discovery and monitoring are ready for production—not merely that a device appeared in a scan. Use these 24 vendor-neutral tests for approved scope, inventory reconciliation, pollers, SNMP security, stable identity, metrics, alert routing, dependency failures, outages, recovery, and acceptance.
Pass Scope, evidence, tests, routing, and ownership all match the approved design.
Conditional A bounded gap has a compensating control, owner, due date, and approver.
Stop The polling chain, credential security, freshness, ownership, or outage test is missing.
1. Scope and architecture
Approve the device and site denominator Name every included site, subnet, and device class; record exclusions and the expected count before discovery begins.
Evidence: approved site and subnet list, device classes, exclusions, expected count. Reconcile discovery with authoritative inventory Review stale, duplicate, transient, unauthorized, missing, renamed, and replaced devices instead of treating a scan as the system of record.
Evidence: timestamped exports, durable identifiers, lifecycle states, reconciliation owner. Document the complete polling path Map poller, network route, protocol, port, credential, and target so a broken dependency is not mistaken for a device outage.
Evidence: dependency diagram and separate poller-versus-target failure tests. Validate poller placement and capacity Keep customer and site boundaries explicit, baseline the poller host, and prove representative target volume stays within the freshness window.
Evidence: poller host, boundary, target count, interval, resource baseline, load result. 2. Protocol and identity
Test the approved protocol and port Do not equate ping with monitoring. Prove the exact source, destination, protocol, port, and firewall path used for collection.
Evidence: connection test and a port-block test with ICMP left available. Set a secure SNMP and credential policy Where supported, evaluate authenticated and privacy-protected SNMPv3. Store secrets outside documentation and test rotation and revocation.
Evidence: version, auth/privacy settings, secret-store reference, rotation test. Restrict the monitoring view Expose only the objects needed for approved inventory and health checks. Record and review any broader read access.
Evidence: allowed view, successful approved query, expected excluded-object denial. Prove stable target identity Use durable evidence beyond IP address and display name so DHCP, replacement, stacking, and failover do not create silent duplicates.
Evidence: management address, sysObjectID, serial or chassis ID, model, site, source. 3. Metrics and baselines
Inventory supported MIBs and objects Discovery does not prove that the platform collects the vendor-specific health objects operators require.
Evidence: model and firmware matrix, required objects, value, unit, timestamp, errors. Define availability and freshness separately Document poll interval, missed-poll rule, freshness threshold, and unknown state so stale data never appears healthy.
Evidence: healthy, stale, unknown, and down test results. Baseline interfaces by role Trunks, uplinks, access ports, and expected shutdowns need distinct state, speed, utilization, error, and discard rules.
Evidence: interface role, admin/oper state, baseline, exception owner, alert test. Baseline resource and environmental health Record device-specific units and sustained thresholds for CPU, memory, temperature, power, fan, and storage metrics.
Evidence: normal range, warning and critical thresholds, confirmation window, source. Observe hardware and redundancy state Stack members, power supplies, fans, RAID, UPS batteries, and failover peers can degrade while a device remains reachable.
Evidence: required component states and a bounded redundancy-loss test. Separate polling from traps and syslog Record delivery, retention, attribution, and gap behavior for each signal source instead of treating them as interchangeable.
Evidence: triggered event, collector receipt, timestamp, attribution, deduplication. 4. Alerting and service workflow
Define an actionable alert condition Every rule needs a condition, confirmation window, severity, affected service, evidence, and safe first response.
Evidence: rule and an alert containing target, site, metric, value, threshold, time. Detect shared poller and dependency failures Correlate failed pollers, routes, credentials, and collectors so one dependency does not create a storm of false device outages.
Evidence: dependency rule, parent incident, child behavior, escalation test. Route tickets to an accountable owner Map customer, site, configuration item, severity, queue, owner, escalation, and acknowledgement.
Evidence: warning and critical test tickets with correct context and ownership. Control duplicates and storms Correlate interface, device, dependency, and downstream events into one actionable incident without deleting the underlying evidence.
Evidence: deduplication key, rate limit, parent-child result, preserved event list. Bound maintenance behavior Specify exact scope, collection versus routing behavior, hard expiry, and post-window reconciliation for planned work.
Evidence: short test window, retained data, suppression result, expiry, reconciliation. 5. Resilience and acceptance
Run an end-to-end outage and recovery test Create one bounded outage and measure detection, alerting, ticket routing, restoration, recovery evidence, and closure.
Evidence: start, detection and recovery times, alert/ticket IDs, reviewer. Expose data gaps honestly A collector outage must not convert missing measurements into healthy values or overwrite the last-success timestamp.
Evidence: UI, export, alert, and report examples across a forced collection gap. Recover from poller restart and replacement Prove routine restart, patching, and replacement preserve target identity, credentials, policies, baselines, and collection.
Evidence: restart/replacement procedure, recovery time, target mapping, test result. Keep configuration backup as a separate control Healthy monitoring does not prove a restorable device configuration exists. Name the backup system and test one isolated restore.
Evidence: backup scope, schedule, encryption, restore test, owner. Record acceptance and re-review triggers Approve only the tested device classes, firmware, pollers, credentials, objects, thresholds, routes, and workflows.
Evidence: scope, exceptions, approver, date, next review, change triggers.
Minimum production gate The approved device denominator is reconciled and every target has a durable identity and accountable owner. The polling dependency, credential lifecycle, freshness semantics, alert route, outage, recovery, and data-gap behavior have been tested. Every conditional result has a compensating control, due date, owner, and approver. Network-monitoring checklist questions What must be tested? Scope, inventory, pollers, protocol security, identity, objects, freshness, alerts, dependencies, outages, recovery, and ownership. Does discovery prove monitoring? No. Discovery is only observation; acceptance requires fresh metrics, routing, tested failures, and evidence. Should an MSP use SNMPv3? Evaluate authenticated and privacy-protected SNMPv3 where supported; formally govern any weaker exception. What blocks rollout? Unknown scope, unmanaged credentials, untested dependencies, stale data shown healthy, ownerless alerts, or failed outage and recovery tests. Is this Nizlo-specific? No. It evaluates any platform, including whether Nizlo's current lack of SNMP and network discovery should disqualify it. Relationship and capability disclosure: Nizlo maintains this vendor-neutral checklist. Nizlo does not currently claim SNMP or network-discovery support. Use the checklist to evaluate Nizlo or another platform and to decide whether dedicated network monitoring must remain in the toolset. It is an operational starting point, not a security certification, penetration test, vendor guarantee, or substitute for device-vendor guidance.