In our ongoing series about optimizing your PRTG monitoring setup, we've already covered discovering all your devices, implementing vendor-specific sensors, and extending your monitoring with third-party sensors and templates. Now, it's time to ensure you're actually notified when issues arise.
After all, what's the point of monitoring if you don't know when something goes wrong? The most comprehensive monitoring setup in the world is useless if alerts don't reach the right people at the right time.
At its core, alert handling in PRTG consists of three critical steps:
1️⃣ Detecting a change in state - When a monitored condition crosses a threshold
2️⃣ Sending a notification - Alerting the right people through appropriate channels
3️⃣ Taking action - Responding to and resolving the issue
Each step is essential, but today we'll focus on optimizing the notification process - the bridge between detection and resolution.
Before diving into the technical setup, take some time to plan your notification strategy by answering these key questions:
❓ Which objects require notifications? Not every sensor needs to trigger alerts when its status changes.
❓ Who needs to be notified? Create a responsibility matrix for different systems and time periods.
❓ What notification methods will you use? Consider which communication channels work best for your team.
❓ Do you need automated responses? Determine if you want to trigger scripts or programs when certain alerts occur.
This preparation will save you from notification overload and ensure your alerts reach the right people. Take a look at the following video to get more information about a notification strategy:
PRTG offers an impressive array of notification methods to ensure alerts reach your team:
We recommend configuring at least two different notification methods for critical systems to ensure redundancy. For example, combine email notifications with push notifications to your mobile device.
Not all devices and sensors are equally important. Your notification strategy should reflect the business impact of different systems:
✳️ Critical infrastructure (core routers, firewalls, authentication servers): Immediate notifications at any time
✳️ Business applications (ERP systems, CRM, email): Notifications during business hours, escalation after hours if unresolved
✳️ Secondary systems (development servers, backup systems): Notifications during business hours only
✳️ Monitoring infrastructure (low disk space on monitoring server): Immediate notifications to IT staff
Categorizing your systems this way allows you to create notification templates that match the importance of each category, reducing alert overload while ensuring critical issues receive immediate attention.
Standard sensor status changes (Up, Warning, Down) are just the beginning of PRTG's notification capabilities. For more precise control, you'll want to configure channel limits - thresholds that determine when a sensor's specific metrics trigger notifications.
For example, instead of waiting for a disk space sensor to reach a critical state, you can set custom thresholds to alert you when:
🧩 A production database server reaches 85% disk usage
🧩 CPU utilization stays above 90% for more than 5 minutes
🧩 Memory usage exceeds 75% during business hours
🧩 Response times for your web application exceed 2 seconds
These granular thresholds allow you to address potential issues before they become critical failures.
To learn how to set up these custom channel limits, watch our tutorial on configuring channel limits:
📺 PRTG Tutorial: Channel Limits
What happens when an alert is triggered but nobody responds? For critical systems, the answer should never be "nothing." PRTG allows you to create escalation paths that ensure alerts don't go unnoticed.
A basic escalation path might look like this:
1️⃣ Initial notification to the primary support team
2️⃣ If unacknowledged after 15 minutes, notify the team supervisor
3️⃣ If still unacknowledged after 30 minutes, notify the IT manager
4️⃣ If unresolved after 60 minutes, notify the CIO
This approach ensures that critical issues always receive attention, even if the primary responder is unavailable.
The process of configuring notifications in PRTG follows these five key steps:
✅ Set up notification delivery settings - Configure your email server or SMS gateway
✅ Set up notification contacts - Define who receives alerts
✅ Create notification templates - Specify what information is included and how it's delivered
✅ Define notification triggers - Determine which conditions cause alerts to be sent
✅ Test your notifications - Verify everything works as expected
For a detailed walkthrough of this process, check out our comprehensive guide to setting up notifications in 5 steps.
Ready to optimize your PRTG notifications? Here's what to do:
👉 Audit your current notification setup - Document which alerts are configured and who receives them
👉 Identify gaps and redundancy needs - Determine where additional notification methods or recipients are needed
👉 Configure channel limits - Set appropriate thresholds for critical metrics beyond simple up/down status
👉 Create notification templates - Develop templates for different severity levels and recipient groups
👉 Test thoroughly - Verify that all notification paths work as expected
By implementing a comprehensive notification strategy, you'll transform PRTG from a passive monitoring tool into an active alerting system that helps you address issues before they impact your users.
In next week's article, we'll explore how to organize your growing monitoring environment by grouping sensors into libraries, making your PRTG setup more manageable as it scales.