Most monitoring trials die quietly. Someone signs up, the collector goes on a spare VM, a network map appears, everyone says “nice”, and then the trial expires while the team is busy with a firewall migration. Two weeks later there is a renewal-priced quote and nobody can say whether the product caught anything. Fourteen days is the trial length Auvik has offered at the time of writing and a sensible time box for any tool; check each vendor’s current terms, as they change. This plan uses those two weeks to answer one question: would this product have made last quarter’s outages shorter?
Before day 1: prepare the ground
Do this before you start the clock, because trial days spent waiting for firewall rules are wasted.
- A VM or small server for the collector or probe, on a network segment that can reach your management VLAN.
- Read-only SNMP credentials (SNMPv3 where your gear supports it), plus read-only SSH, WMI or API credentials for anything you want configuration or server data from.
- A short list of three recent incidents with rough timestamps: the WAN drop, the full disk, the switch loop.
- A shared scoring sheet (template at the end) and one named owner who checks the product daily.
Only point the tool at networks you own or are authorized to manage. Scanning a neighbor’s subnet or a provider’s range is out of bounds even during a trial.
Days 1–2: connect and discover
- Start the trial from the vendor’s own website. Our where to get it safely page lists the product URLs.
- Deploy the collector or probe and enter credentials.
- Let discovery run for at least a few hours, then note the time it took.
- Record: how many devices were found, how many were identified correctly (make, model, role), and how many need manual fixing.
A quick test that the collector host can actually poll a switch before you blame the product:
snmpwalk -v3 -l authPriv -u monitor -a SHA -A '<auth-pass>' \
-x AES -X '<priv-pass>' 10.0.10.2 1.3.6.1.2.1.1If that returns the system description, credential problems are ruled out.
Days 3–4: the map and the inventory
Compare the product’s topology map with what you know. Are uplinks between switches drawn correctly? Are VLANs and wireless networks shown? Export the inventory to CSV and check it against your asset list. A tool that cannot build an accurate inventory will not produce accurate alerts either. An independent sweep of the same subnets with Angry IP Scanner is a useful yardstick, and if a device shows as unreachable when you know it is up, a short Wireshark capture on the collector host shows whether the polls are leaving and the replies coming back.
Days 5–6: alerts and noise
Turn on the default alert policy and route it to a test channel (email, Teams or Slack, or your ticketing system). Count the alerts after 48 hours. Then tune: raise thresholds, set dependencies so a dead uplink does not generate forty “device down” messages, and create one maintenance window. Note how long tuning took and whether you needed documentation or support.
Days 7–8: break something on purpose
Controlled failures are the most valuable test you can run. During an approved change window:
- Unplug a redundant uplink or shut a switch port.
- Stop a non-critical service on a test server.
- Fill a test volume past your disk threshold.
- Let a lab certificate expire, or point a check at an expired test site.
For each, record time to alert, whether the alert named the root cause, and whether it cleared on its own when you restored service.
Days 9–10: reporting and history
Build the two reports your manager actually asks for: monthly availability for key services, and bandwidth use on the internet links. Check how far back history goes at full resolution and whether graphs can be shared without handing out an admin login.
Days 11–12: people and integrations
Add a second admin with restricted rights. Connect the ticketing or chat integration. If you are an MSP, create a second tenant or site. Open one real support ticket with a genuine question and time the response.
Day 13: the cost conversation
Ask the vendor for a written quote based on the counts from your trial, not your guess. Ask specifically about renewal price, what happens when you exceed the licensed number, and which features in the trial are in a higher tier. Our pricing models guide explains how the different counting units behave.
Day 14: score and decide
| Criterion | Weight | Score 1–5 | Notes |
|---|---|---|---|
| Discovery accuracy | 15% | ||
| Map and inventory quality | 10% | ||
| Alert quality after tuning | 20% | ||
| Controlled-failure results | 20% | ||
| Reporting | 10% | ||
| Integrations and roles | 10% | ||
| Support response | 5% | ||
| Three-year cost | 10% |
Common mistakes in trials
- Running two products in the same fortnight with one engineer. Stagger them, or both trials get half attention.
- Testing only in the head office. Include one branch or remote site.
- Judging by the dashboard screenshot rather than by the controlled failures.
- Letting the trial expire before the quote arrives. Most vendors will extend a trial if you ask before it ends.
Which tools to trial
Cloud-managed products such as Auvik and NinjaOne are quick to stand up; PRTG, including PRTG Hosted Monitor, covers servers and applications as well as network gear. See Auvik vs PRTG for that choice, the cloud-managed shortlist for alternatives, and our methodology for how we run these tests ourselves. Write your must-haves down first with the requirements checklist.