Network Monitoring Checklist: Requirements to Verify

Short answer: A network monitoring checklist should describe the devices, measurements, sites and incident decisions your team needs to support. For each requirement, name a trial test and the evidence needed to pass it. A feature label in a sales deck is not enough: verify collection from your equipment, interpretation of its data, and delivery of an actionable alert.

How we built this network monitoring checklist

This worksheet follows the ten criteria in the Network Monitoring evaluation framework and the operational questions that a buyer needs to test. The ten evaluation areas are editorial priorities, not scores for any product. Adjust the priorities to your environment before sending the worksheet to a vendor.

Protocol details come from the Interfaces Group MIB and the SNMPv3 security and access control specifications. NIST SP 800-137 explains why monitoring needs ongoing visibility into assets and controls. The table below proposes verification steps; it does not claim every software product supports them.

For vendor answers, use "Not published" when a vendor has not documented a limit or feature. Use "Not tested" when the documentation exists but your trial has not yet proved it. Keeping those states separate prevents an unknown from becoming a false negative or an assumed yes.

Define the network you need to observe

Inventory the network questions before listing tools. Identify the routers, switches, firewalls, wireless equipment, virtual networks and external paths in scope. Record the model, firmware, management address and owner for each representative device. Note which branch or customer site it belongs to and where a collector could reach it.

Then name the actions you expect an operator to take. A busy uplink may need interface rates and errors; a path complaint may need a measurement from the user-facing location; a disconnected branch may need a local collector with delayed forwarding. Google's SRE monitoring guidance stresses actionable signals over monitoring for its own sake. Use that principle to cut measurements no one will interpret.

Set three levels for the worksheet: Must, Should and Could. A Must is required to run an incident workflow; a Should improves it; a Could is useful but not decisive. Have the network and service owners agree on these levels before looking at vendor demonstrations.

Network monitoring requirements matrix

Copy these rows into a trial sheet. Give each vendor an answer and a link to its documentation. Use the last column during an evaluation on your own equipment. A test passes only when the named operator can interpret the result and reproduce the evidence.

Priority values are suggestions. For a small office without remote sites, remote-site behavior may not decide the purchase. For an MSP, tenant separation and per-client alert routing should become Must requirements. If a vendor cannot document a limit, record the uncertainty in the same row as the requirement it affects.

Test the difficult readings, not only device discovery

A collector discovering a device proves little about the measurements needed for an incident. Pick a known interface and compare its identity, speed, operating state and counters with the device's own records. RFC 2863 defines high-capacity octet counters and ifCounterDiscontinuityTime. Ask the vendor how the application avoids making a reset look like a traffic spike.

For a hypothetical calculation, an increase of 60,000,000 octets over 60 seconds is an average of 8,000,000 bits per second if there was no reset or wrap. That does not show a peak within the minute. Compare the monitoring report with the raw counter and interval used to calculate it.

Do the same for alerts. A successful poll does not prove that a device notification arrives, and a received notification does not prove that an on-call person sees an incident. Configure each path you intend to use, generate an approved test condition, and record the result at the receiver and notification destination. Keep maintenance behavior in the test so a planned change does not teach operators to ignore alerts.

A topology demonstration needs a known wrong or missing connection. Ask the product to show the evidence behind the line and the collection time. Label any manual correction and give it an owner. A freshly drawn page can still represent old data; what matters is when the underlying source was observed.

Run a trial with pass criteria

The trial should be small enough to inspect but varied enough to expose blind spots. Include one ordinary device, one site with constrained reachability and one device or interface with incomplete data. The following tests are suggested acceptance criteria, not results we observed.

Have a network operator, not just a salesperson, walk through the findings. Record the configuration used, whether the device was reachable and which requirements remain unproven. A failed trial can be useful if it identifies a genuine limit you can plan around.

Keep a decision record you can defend

After the trial, give each requirement a status: Passed, Failed, Not tested or Not published. Attach the evidence link, observation date and reviewer. Record the consequence of any Must requirement that did not pass, and whether the vendor has a documented workaround. Do not turn an unknown into a numeric score.

Compare total cost only after identifying the billable unit. Devices, interfaces, sensors, collectors and retained data can create different invoices. Ask for a quote using your actual sites and expected growth, and write down what changes the price. Keep contract and support questions on the same sheet as the technical tests.

For the final choice, explain the conditions under which it would change. A platform that collects the required interface data but cannot place a collector at a remote site may suit headquarters and fail the branch requirement. A tool with strong path visibility but weak device counter coverage may need a second data source. State these trade-offs from tested evidence, not assumed feature lists.

Bottom line

Choose the one incident question your current tools cannot answer, then test each candidate against the data and workflow needed to answer it. Keep unknowns visible in the decision record. Use the network monitoring category to identify candidates and your software shortlist to compare the finalists.