Methodology

The evidence test

Troubleshooting ends in a conversation with someone else: an ISP, a SaaS vendor, a hosting provider, the colleague who owns the firewall. That conversation goes faster when you can show rather than describe. So instead of counting features, we ask what artefact each tool leaves you with — a per-hop report, a latency graph over two weeks, a pcap, a throughput log, a before-and-after host list — and whether a person outside your team could read it and reach the same conclusion.

The second half of the test is time. A tool that produces perfect evidence after a day of setup is the right answer for a recurring problem and the wrong one for a ticket that is burning now. For each tool we estimate, from its documentation and setup requirements, how long a competent admin who has never used it would need to get from the vendor’s site to a first piece of usable evidence. These are reasoned estimates, stated as such, not stopwatch measurements.

Where the information comes from

• The vendor’s own material: product pages, documentation, licence terms, pricing pages, release notes and changelogs. This is our source for every fact about licensing, price model, platforms and versions.
• Public demos and trials, where a vendor offers them, to understand what the interface and reports actually present.
• Commonly reported admin experience — forums, issue trackers, mailing lists, support threads — for the strengths and failure modes that only show up after long use. We treat single anecdotes cautiously and look for patterns.
• Protocol behaviour that is independently documented, such as how routers rate-limit ICMP or how TCP window size limits a single stream. When we explain why a tool shows what it shows, it rests on this.

We do not claim first-hand lab results. Where a page gives an example — a trace, a command, a typical result on a small office network — it is labelled or phrased as illustrative.

Six criteria

1. Evidence quality. Is the output exportable, timestamped and specific (addresses, hop numbers, sample counts)? Would it survive being forwarded?
2. Time to first evidence. Setup steps, dependencies, whether a far-end component or agent is required, and how much reading the output demands.
3. Where it can run. Operating systems, whether it can run on the affected machine or site, and whether it needs elevated rights.
4. Honest licensing. Is the licence clear? Is “free” genuinely free for business use? Are prices published or hidden behind a sales call? We describe the model and date any figures.
5. Maintenance. Release cadence and supported-platform lists. A tool with no release in years is flagged, even if it still works.
6. Safe sourcing. Signed builds, published hashes or reliable package-manager availability, so admins can get a genuine copy.

How category tables are ordered

Each category page lists its tools in the order we would suggest trying them for a typical small or mid-size network, weighing the first two criteria most heavily. Tools that mainly belong to another category appear lower as supporting options. No vendor can buy, request or influence a position, and no link on the site pays us anything.

What every review includes

What the tool does, where it is strong, where it falls short and who should skip it, who it suits, licensing and cost, how it compares with alternatives on the site, and how to get it safely from the vendor. Weaknesses are mandatory: a review without a “who should not use this” section is not finished.

Updates and corrections

Every page shows the date it was last reviewed. We re-check licensing, pricing models and supported platforms when vendors publish significant releases and in periodic sweeps of the whole catalogue. If you spot something out of date, write to editor@scan365pro.ink; see also who runs Scan 365 Pro.