Every monitoring system has one blind spot shaped exactly like itself. If the probe is overloaded, your green dashboard may just be a machine too busy to notice trouble.
PRTG's probe is the worker that runs every sensor - pinging, polling WMI, swallowing flow records. The core server draws the pictures, but the probe produces the truth. An unhealthy probe fails in the worst way: not with an alarm, but with gaps, delays and sensors queued so long their data is history by the time it lands. This closing guide is the maintenance routine that keeps the watcher worth believing.
Paessler's own planning guidance names them. WMI weight: keep a probe near 120 WMI sensors at a 60-second interval (about 600 at 300 seconds). Flow volume: flow sensors cost in proportion to the traffic they summarise. Packet sniffing: the heaviest method of all - recommended only for low-traffic links (under roughly 50 Mbit/s steady) or on a dedicated remote probe. None of these is a reason to panic at small-office scale; all three are reasons to know your counts.
Halving a scanning interval doubles the probe's work for that sensor. Ask what each interval buys: ping on the firewall at 30 to 60 seconds is vigilance; disk free space at 60 seconds is superstition - disks fill over hours, so five minutes loses nothing. Lengthening intervals on slow-moving values is the cheapest probe upgrade that exists, and it costs you nothing you were ever going to use.
Monitoring data grows. Set retention to what you truly need, keep the PRTG machine's disk comfortably free, install PRTG updates on a calm schedule (it is a Windows server - patch it like one), and back up the configuration before major changes. Once a quarter, do the cruel test: pull the network cable on a test device and time how long until the alert reaches a phone. That number - not the dashboard's beauty - is your monitoring system's real specification.
Every sensor in this guide is created live in the video - installation, discovery, CPU and RAM, bandwidth and firewall status.
Watch Full VideoSymptoms before errors: sensor intervals slipping, 'delayed' scans, gaps in graphs at busy hours, and the probe health sensors complaining. The fix ladder is intervals first, heavy sensor types second, a remote probe third.
When one probe cannot keep up, when a second site needs local eyes, or when one heavy job - packet sniffing a busy link - deserves its own worker. Remote probes report to the same core server, so the dashboard stays single.
Inside one system, only partly - that circularity is why the external check matters. A simple Uptime Kuma instance on a different box watching the PRTG web page, plus PRTG's own health sensors, covers each other's blind spots well enough for a small office.