The first week of monitoring, every alert is exciting. By the fourth week of false alarms, somebody creates an email filter - and the real outage arrives in silence. Alert design is the whole game.
PRTG can notify by email, app push, SMS gateways and more, the moment a sensor changes state. That power has a known failure mode: alert fatigue. A CPU that kisses 100 percent for eight seconds during a backup is not an incident; a disk filling for three weeks is not an emergency - until the last day, when it suddenly is. This page is the discipline that separates the two: thresholds with intent, warning before error, and delays that forgive blips.
A threshold should answer: at what value must a human do something? CPU warning at 90 percent sustained is actionable; CPU at 100 for one scan is weather. Disk free space belongs in percent and days: warn early enough that ordering a drive or cleaning up fits inside a working week. Write the action next to the threshold in your own notes - a threshold with no agreed action is a future false alarm.
PRTG sensors carry a warning state before down/error, and channel limits let you define both. Route them differently: warnings collect into a daily glance or a morning summary; errors page a person now. This one separation halves alert noise instantly, because most real problems walk through warning on their way to error - you meet them early, calmly, in the summary, instead of at 3 AM.
Notification triggers can wait: only notify if the state persists for, say, 5 or 10 minutes, and escalate if it persists longer. A router rebooting during its own firmware update, a WAN that flaps for ninety seconds - these self-heal inside the delay and never wake anyone. Keep delays short or zero only where seconds truly cost money. Everything else earns the right to be believed by sometimes staying silent.
Every sensor in this guide is created live in the video - installation, discovery, CPU and RAM, bandwidth and firewall status.
Watch Full VideoAs fast as the business feels it: the scan interval plus a short confirmation. For most offices a ping down confirmed over two or three scans - a few minutes - beats an instant alert on every dropped packet, and the delay is what keeps the alert credible.
That is a blip the delay should have absorbed - the state cleared before a human needed to know. Lengthen that trigger's delay, or move the threshold. Self-healing events belong in the history graph, not in the inbox.
No. Most sensors exist for graphs and diagnosis after the fact. Notifications belong on the small set where a human's timely action changes the outcome - availability of key devices, disk space, WAN saturation and your firewall's serving layer.