PRTG network monitoring: review, pricing, and alternatives

PRTG's entire monitoring capability is organized around the sensor concept: every individual metric monitored is a discrete sensor that consumes one unit of the license count. A sensor might check device availability via ICMP ping, poll a specific SNMP OID for CPU utilization, monitor an HTTP endpoint for response time and status code, capture NetFlow data from a router interface, or poll a REST API for a JSON value. - This architecture gives PRTG its unusual flexibility — any monitoring requirement that can be expressed as a metric or a status check can be addressed by combining built-in sensor types or by writing a custom sensor script. - Limitation: Sensor count planning becomes a management discipline: each additional metric the team wants to monitor consumes a sensor from the licensed pool, and unplanned sensor expansion can exhaust a tier before the next renewal period.

PRTG's core network monitoring capability covers SNMP v1, v2c, and v3 for network device polling, ICMP for availability and latency monitoring, and WMI for Windows host monitoring without an agent. SNMP sensors support custom OID polling — any value exposed by a device's MIB can be monitored without waiting for Paessler to build a device-specific integration. - PRTG ships with a library of device-specific sensor templates for common vendors: Cisco, Juniper, HPE, Fortinet, Palo Alto, and dozens more, which pre-populate the most useful OIDs for each device type. - WMI sensors monitor Windows servers and workstations directly through the Windows Management Instrumentation interface — CPU, memory, disk, event log entries, services, and running processes are all accessible without deploying an agent on the monitored host.

PRTG includes built-in support for network flow analysis using NetFlow v5, NetFlow v9, IPFIX, sFlow, and jFlow — all within the core product with no additional module required. Flow data is collected from capable routers and switches and analyzed to produce bandwidth consumption reports by application, conversation pair, protocol, and top talker. - For environments where routers and switches do not support flow export, PRTG's Packet Sniffing sensor captures and analyzes traffic from a monitored network interface, providing flow-like visibility without requiring hardware flow support. - The combination of flow analysis and packet sniffing means PRTG can deliver traffic visibility for network hardware across a wide range of vendor capabilities.

PRTG's distributed monitoring architecture uses remote probes — lightweight software components installed at remote sites — that collect monitoring data locally and transmit results to the central PRTG server over an encrypted connection. - Remote probes enable monitoring of devices at locations where the PRTG server cannot reach directly: branch offices, remote data centers, cloud VPCs, or isolated network segments behind firewalls. - For enterprise environments with multiple sites, remote probes are the architectural mechanism that makes comprehensive monitoring practical — a single PRTG server can aggregate data from dozens of probe deployments, each monitoring its local network segment, into a unified console.

PRTG includes a dashboard and network map editor that allows administrators to build visual representations of the monitored infrastructure. Network maps support background images — network topology diagrams, floor plans, geographic maps — over which device icons and sensor status indicators are overlaid. - When a device goes into alert status, its icon changes color on the map in real time, giving the operations team a visual overview of the monitoring state at a glance. - Both dashboards and maps are shareable via URL and configurable for read-only access, which allows network operations screens and team-level views without requiring every viewer to have an administrator account.

PRTG's alerting engine supports multiple notification methods: email, SMS, push notifications (via the PRTG app), Slack messages, webhook calls, Syslog forwarding, SNMP traps, Amazon SNS, and custom scripts for any notification target. Alert conditions can be defined at the device level, the group level, or the sensor level, with threshold-based triggers (above/below a value), state-change triggers (sensor transitions to down or warning status), and schedule-based suppression to prevent alert noise during planned maintenance windows. - Escalation chains allow alerts to be routed to a first contact, then escalate to a secondary contact if the alert is not acknowledged within a configurable time window. - This dependency awareness is one of PRTG's most practically useful alerting features for complex environments where parent device failures would otherwise generate hundreds of simultaneous notifications.

PRTG's sensor library extends well beyond traditional network and server monitoring into industrial and IoT protocol territory, which distinguishes it from monitoring tools focused purely on IT infrastructure. The REST API sensor monitors any HTTP/HTTPS endpoint that returns JSON or XML data, extracting specific values from the response for monitoring — enabling monitoring of web services, cloud APIs, custom application endpoints, and any system that exposes metrics via a REST interface. - MQTT sensors subscribe to topics on an MQTT broker and monitor published values, enabling monitoring of IoT sensors, smart building systems, industrial machines, and any device that uses the MQTT publish/subscribe protocol. - Modbus sensors poll Modbus TCP and Modbus RTU devices — industrial controllers, PLCs, energy meters, environmental sensors — using the serial or TCP Modbus protocol. - These industrial protocol sensors make PRTG a practical choice for organizations that manage OT (operational technology) infrastructure alongside traditional IT networks, without requiring a separate industrial monitoring system.