3 results found

1. Distinct "Attention" Alert State for Update/Patch Compliance Sensors (WSUS)

   As a Systems Engineer responsible for patching and system health,
   I want Windows Updates Status / WSUS sensors to display a visually distinct alert state (e.g., a purple "Needs Attention" status) instead of the standard Warning/Down states
   so that I can immediately distinguish "system is not up to date" from "system is broken" in the device tree, alarms list, and dashboards — and triage genuine outages first without losing sight of patch compliance issues.

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Under Review  ·  1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. Disable Acknowledge Alert

   In the GUI and in the HTML notification emails, there is an "Acknowledge Alert" which shifts the "Down" to "Down (Acknowledged)" this moves the state which then triggers the "leaving Down" trigger, but the sensor is still down.
   
   With the shift in state from "Down" the escalation settings are negated along with any other notification triggers set to trigger on "down" state after 10 minutes.
   Secondary, there is no notification trigger state for the "Down (Acknowledge)" so there is no way to have an escalate notification trigger.

   Additionally, each of the user groups have the "Ticket System Access" set to "Do not allow user group members to use the ticket system" which would imply that all users should not have any sort of state/ticket ability to shift the state.

   In the GUI and in the HTML notification emails, there is an "Acknowledge Alert" which shifts the "Down" to "Down (Acknowledged)" this moves the state which then triggers the "leaving Down" trigger, but the sensor is still down.
   
   With the shift in state from "Down" the escalation settings are negated along with any other notification triggers set to trigger on "down" state after 10 minutes.
   Secondary, there is no notification trigger state for the "Down (Acknowledge)" so there is no way to have an escalate notification trigger.

   Additionally, each of the user groups have the "Ticket System Access" set to… more

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Under Review  ·  0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Allow Unusual Detection to be disabled per-sensor

   As a Network Engineer monitoring devices with heterogeneous sensor profiles,
   I want to override the inherited Unusual Detection setting on an individual sensor (analogous to how channel limits can be set at sensor level),
   so that I can silence chronic false-positive "Unusual" states on noisy low-value sensors (e.g., near-zero-traffic uplinks, msec-level Service sensors) without losing Unusual Detection on the device's other sensors and without splitting one physical device across multiple PRTG device objects.

   Background:
   Unusual Detection is currently inherited from Probe/Group/Device level, there's no per-sensor toggle. This becomes a problem when a device has a mix of sensors, some of which are good candidates for Unusual Detection and some that aren't, but you can't turn it off for just the noisy ones without also losing it on the useful ones.

   Example: our core switch has 6 sensors — 5 are legitimate WAN/uplink traffic sensors with real day/night usage patterns where Unusual Detection is valuable (a sudden drop or spike is a real signal). The 6th is a near-zero-traffic uplink (<0.01 Mbit/s) where any normal jitter reads as a huge percentage swing, so it shows "Unusual" constantly even though nothing is wrong. The same issue shows up on low-execution-time Service sensors (msec-level execution times naturally jitter and trip the same false positive).

   The current workaround is to move the noisy sensor onto its own dedicated device object and place that device in a separate group with Unusual Detection disabled, which means splitting one physical device's sensors across multiple PRTG device objects just to silence one sensor's false positives.

   Request: add a per-sensor override for Unusual Detection (similar to how channel limits can already be set per-sensor), so a single chronically noisy sensor can be silenced without restructuring the device hierarchy or losing detection on the rest of the device's sensors.

   As a Network Engineer monitoring devices with heterogeneous sensor profiles,
   I want to override the inherited Unusual Detection setting on an individual sensor (analogous to how channel limits can be set at sensor level),
   so that I can silence chronic false-positive "Unusual" states on noisy low-value sensors (e.g., near-zero-traffic uplinks, msec-level Service sensors) without losing Unusual Detection on the device's other sensors and without splitting one physical device across multiple PRTG device objects.

   Background:
   Unusual Detection is currently inherited from Probe/Group/Device level, there's no per-sensor toggle. This becomes a problem when a device has a mix of sensors, some of… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Under Review  ·  0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating