A common estimating mistake looks like this: multiply the device count by the “about ten sensors per device” rule of thumb and land on 800, then watch auto-discovery on day two of the trial produce 1,340 instead. Nearly all of the difference usually comes from switch ports nobody had planned to watch. Paessler sells PRTG as a subscription tiered by sensor count, both for a self-hosted core server and as PRTG Hosted Monitor, so getting this number right is the single biggest lever on what you pay. Here is a more reliable method.
What counts as one sensor
In PRTG a sensor is one monitored aspect of one device. A ping to a switch is one sensor. The traffic on port Gi1/0/12 of that switch is another. The CPU load of a server is one, and each disk volume on that server is one more. Some sensors return many channels (a hardware-health sensor might report fans, temperatures and power supplies together), and channels do not cost extra. The license counts sensors, not channels, devices or metrics.
A few sensors are overhead you never asked for: the core, each probe and the system itself report their own health. Plan on a handful per probe.
Sensors per device type
These are the counts we use as a planning baseline. They assume you watch what matters, not everything auto-discovery offers.
| Device type | Typical sensors | Count |
|---|---|---|
| Managed switch | Ping, SNMP uptime, CPU, memory, hardware health, plus one traffic sensor per used port you care about | 5 + N ports |
| Core / chassis switch | As above, plus power supply and module sensors | 8 + N ports |
| Firewall / router | Ping, uptime, CPU, memory, one traffic sensor per WAN/LAN/VPN interface, VPN tunnel status, HTTPS on the management page | 8–15 |
| Wireless controller | Ping, uptime, CPU, memory, client count, one sensor per AP group | 6–10 |
| Access point (standalone) | Ping, uptime, traffic | 3 |
| Windows server | Ping, CPU, memory, one disk-capacity sensor per volume, network card, uptime, pending updates, 2–4 key services | 9–12 |
| Linux server | Ping, SSH load average, memory, one disk sensor per mount, SNMP traffic, 1–2 process checks | 7–10 |
| Hypervisor host | Host health, CPU, memory, datastore per datastore, optionally one sensor per VM | 6 + VMs |
| NAS / storage | Ping, SNMP disk/volume per pool, system health, traffic | 6–10 |
| Web app / public site | HTTP(S) response, SSL certificate expiry, DNS resolution | 3 |
| Printer | Ping, SNMP printer status (toner, paper), uptime | 2–3 |
| UPS | Ping, SNMP battery status, load, runtime | 3–4 |
| IP camera / IoT | Ping only | 1 |
Step-by-step estimation
- Export your inventory. Pull a device list from your switch MAC tables, DHCP scopes, hypervisor console or asset system. A spreadsheet with a “type” column is enough. If the records are stale, a quick sweep of your own subnets with a free scanner such as Angry IP Scanner gives you an independent count to start from.
- Group by type and apply the table. Use the lower number for devices you merely need to know are up, and the upper number for anything business-critical.
- Count ports honestly. For each switch, write down how many ports you actually need traffic graphs for: uplinks, server ports, firewall links, storage links. Access ports feeding desk phones rarely earn a sensor.
- Add probe overhead. Roughly 3–5 sensors per probe, and one remote probe per branch site that PRTG Hosted Monitor or your core cannot reach directly.
- Add growth headroom. We add 20% for the first year and then check the tier boundary.
- Validate in the trial. Run auto-discovery on one representative site, prune what you do not want, and compare the pruned count with your spreadsheet.
A simple spreadsheet formula keeps the estimate honest:
total = Σ(devices_of_type × sensors_per_type)
+ Σ(monitored_switch_ports)
+ (probes × 4)
planned_tier = next tier ≥ total × 1.2Worked example: a 45-device office
| Group | Qty | Sensors each | Subtotal |
|---|---|---|---|
| Firewall | 1 | 12 | 12 |
| Access switches, 5 base + 14 monitored ports each | 3 | 19 | 57 |
| Core switch, 8 base + 20 monitored ports | 1 | 28 | 28 |
| Access points | 8 | 3 | 24 |
| Windows servers | 6 | 11 | 66 |
| Linux servers | 3 | 8 | 24 |
| Hypervisor hosts (VMs counted above) | 2 | 8 | 16 |
| NAS | 1 | 8 | 8 |
| Public website + VPN portal | 2 | 3 | 6 |
| Printers | 5 | 3 | 15 |
| UPS | 2 | 4 | 8 |
| IP cameras | 11 | 1 | 11 |
| Probe/system health | 1 probe | 4 | 4 |
| Total | 45 devices | 279 |
With 20% headroom that becomes about 335 sensors, which sits comfortably inside a 500-sensor tier. Had the team let auto-discovery add a traffic sensor to all 48 ports on each of the four switches, the switch count alone would have risen from 85 to about 220, pushing the total past 400 and, with headroom, right up against the 500 boundary. Same office, same devices, but in practice you would be buying the next tier to stay safe.
Mistakes that inflate the count
- Accepting every discovered sensor. Auto-discovery is a starting point. Pause or delete the noise before the trial ends so your final count reflects intent.
- Monitoring every VM twice. If you watch VMs through the hypervisor sensor and as individual devices, you pay twice for similar data. Pick one layer per workload.
- Per-service sensors for everything. Watch the services that break the business: database, print spooler, backup agent. Leave the rest to the OS health sensors.
- Forgetting branch probes. Every remote site adds its own overhead and usually a few WAN-specific sensors.
Going further
Sensor count is one input to cost; renewal terms and server resources are the others. Our pricing models guide compares per-sensor licensing with per-device and per-node models on a 60- and 600-device network. If you are weighing PRTG against a per-device product, read PRTG vs OpManager, and see the small-business shortlist for alternatives. Start any trial from the vendor’s own site; our where to get it safely page lists the official product pages, and methodology explains how we review.