Hello, thanks for submitting the idea have you considered using the PRTG Unusual Sensor detection? It can detect metrics that do not move (i.e., static or unchanging metrics), but it depends on the context and configuration of the sensor and the Unusual Detection feature in PRTG.
How PRTG Unusual Detection Works
PRTG’s Unusual Detection feature identifies anomalies by comparing current sensor data to historical data over a specific time period (typically a 24-hour average compared to the average of the same weekday over the past four weeks). It flags a sensor as “Unusual” when the current values deviate significantly from the historical norm, based on predefined thresholds (e.g., 24-hour average is <80% or >120% of the weekday average).[](https://kb.paessler.com/en/topic/64957-unusual-sensor-explain)
For metrics that remain static (unchanging or near-constant values), PRTG’s Unusual Detection could theoretically flag them as unusual if the metric suddenly starts or stops moving in a way that deviates from its historical behavior. For example:
- If a metric is typically static (e.g., a counter that rarely changes, like the number of active VPN connections or a service status) and suddenly starts fluctuating, PRTG might detect this as unusual.
- Conversely, if a metric that usually fluctuates (e.g., network traffic or CPU load) becomes static, this could also trigger an Unusual status, as it deviates from the expected pattern.
Limitations for Static Metrics
However, there are some nuances to consider:
1. Applicability to Metric Sensors: Unusual Detection is primarily designed for sensors that collect numerical metrics (e.g., traffic, response time, CPU load) rather than binary or state-based sensors (e.g., ON/OFF or UP/DOWN). For sensors that only report binary states (like a VPN status), the Unusual Detection engine typically ignores them, as small value changes (e.g., from 1 to 2) can result in large percentage deviations that aren’t meaningful.[](https://helpdesk.paessler.com/en/support/solutions/articles/76000068153-unusual-sensor-explain)
2. Historical Data Requirement: Unusual Detection requires at least four weeks (28–34 days) of historical data to establish a baseline for comparison. If a sensor has insufficient historical data or if the metric is consistently static, PRTG may not have enough variation to evaluate whether the static behavior is “unusual.”[](https://www.paessler.com/manuals/prtg/monitoring)
3. Sensor-Specific Behavior: For sensors monitoring metrics that are inherently static or have low variability (e.g., sensor execution time for a Windows Service sensor), Unusual Detection might not be useful and could generate noise. For instance, static metrics like service execution times or counters that rarely change might trigger false positives, as noted in user feedback about disabling Unusual Detection for specific sensors to reduce irrelevant alerts.[](https://helpdesk.paessler.com/en/support/solutions/articles/76000076149-feature-request-unusual-sensor-detection)[](https://kb.paessler.com/en/topic/81141-open-enable-disable-unusual-detection-on-sensor-level)
Practical Implications
If you’re specifically concerned about detecting metrics that “do not move” (e.g., a metric stuck at a constant value when it should fluctuate), Unusual Detection might flag this as an anomaly if the metric’s historical data shows regular changes. However, PRTG’s Unusual Detection is not explicitly optimized for detecting stuck or frozen metrics. To address this more effectively, you could:
- Set Channel Limits: Configure specific thresholds for sensors to trigger warnings or errors if a metric remains static for too long (e.g., set a minimum threshold to detect when traffic drops to zero).[](https://kb.paessler.com/en/topic/8583-how-do-i-customize-detection-for-unusual-sensor-status-in-prtg)[](https://helpdesk.paessler.com/en/support/solutions/articles/76000063983-how-do-i-customize-detection-for-unusual-sensor-status-in-prtg)
- Use Custom Notifications: Create a notification trigger to alert you if a sensor’s value remains unchanged for a specified period, which can be more precise for detecting stuck metrics.
- Disable Unusual Detection for Static Metrics: If static metrics are triggering too many false positives, you can disable Unusual Detection for specific devices or groups under “Settings → Advanced Network Analysis” or globally via “Setup → System Administration → Monitoring.” Note that sensor-level granularity for enabling/disabling Unusual Detection is not currently supported, though it’s a requested feature.[](https://kb.paessler.com/en/topic/62070-unusual-detection-for-certain-sensors-only)[](https://helpdesk.paessler.com/en/support/solutions/articles/76000076149-feature-request-unusual-sensor-detection)[](https://kb.paessler.com/en/topic/81141-open-enable-disable-unusual-detection-on-sensor-level)
Recommendations
To confirm whether PRTG’s Unusual Detection is flagging static metrics in your environment:
1. Check the sensor’s historical data in PRTG to see if the metric typically fluctuates or remains static. You can view this in the sensor’s “Historic Data” tab.
2. Review the Unusual Detection settings under Setup → System Administration → Monitoring to adjust the granularity (e.g., change the threshold from “<80% or >120%” to a stricter or looser setting).[](https://kb.paessler.com/en/topic/8583-how-do-i-customize-detection-for-unusual-sensor-status-in-prtg)[](https://helpdesk.paessler.com/en/support/solutions/articles/76000063983-how-do-i-customize-detection-for-unusual-sensor-status-in-prtg)
3. If static metrics are causing unwanted Unusual statuses, consider disabling Unusual Detection for the parent device or group, or use channel limits to better control alerting for static behavior.[](https://kb.paessler.com/en/topic/62070-unusual-detection-for-certain-sensors-only)
4. For a more tailored approach to detecting stuck metrics, consider using a custom script sensor (e.g., an EXE/Script sensor) to monitor for unchanging values and trigger alerts based on your specific logic.[](https://www.paessler.com/manuals/prtg/list_of_available_sensor_types)
If you’re dealing with a large number of sensors (e.g., thousands), managing Unusual Detection can become noisy, as noted in user feedback. In such cases, selectively enabling it for critical sensors (like network interfaces) while disabling it for less relevant ones (like Windows Service execution times) can help.[](https://helpdesk.paessler.com/en/support/solutions/articles/76000076149-feature-request-unusual-sensor-detection)[](https://kb.paessler.com/en/topic/81141-open-enable-disable-unusual-detection-on-sensor-level)
If you need further assistance or want to dive deeper into configuring PRTG for specific static metric scenarios, please provide more details about the sensors or metrics you’re monitoring.