3 results found

1. Disable Unknown State

   As a cybersecurity engineer, I want to avoid unknown states.
   We manage a large number of devices across many different sites, and sometimes we lose SNMP data for a specific sensor. When this happens while the sensor is actually in a down state, the status transitions follow this pattern:
   Down → Unknown → Down.
   This generates a lot of phantom notifications, and even worse, our acknowledged alerts revert to an unacknowledged state.
   Could you please add an option to ignore or bypass the unknown state in such cases?

   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

   0 comments  ·  Delete…  ·  Admin →
   Declined  ·  AdminIsidora Jeremic (Admin, Paessler) responded

   Hi there,

   Thank you again for submitting your idea to Paessler. We truly appreciate you taking the time to share your feedback.

   After careful consideration by our team, we've decided to decline this idea at this time.

   Please note that we don't have plans to remove the Unknown state, as it is a fundamental part of PRTG's architecture.

   Down state occurs when PRTG successfully contacts the target device, but the monitored element is not functioning properly.

   Unknown state occurs when PRTG cannot retrieve any information about the sensor's current state, usually due to a disconnected probe or network issue.

   In your scenario (Down → Unknown → Down), what's happening is:

   1. Your sensor is genuinely down (device/interface issue)
   2. The network path fails (probe-to-device or probe-to-core connection)
   3. Sensor transitions to Unknown (PRTG cannot retrieve status)
   4. Connection restores
   5. Sensor returns to Down (original issue still exists)

   While we cannot disable the Unknown state, here are several alternatives to try:

   1. Use Dependencies

   Configure dependency relationships so child sensors automatically pause when parent connectivity fails: https://www.paessler.com/manuals/prtg/dependencies

   2. Adjust Notification Triggers

   • Add latency settings to avoid alerts during brief interruptions
   • Create separate notification profiles for critical vs. non-critical sensors

   3. Increase Scanning Intervals

   Give intermittent connections more time to recover before status changes trigger.

   While this particular idea won't be moving forward, please don't be discouraged! Your input is incredibly valuable, and we encourage you to continue sharing your thoughts and ideas with us.

   Thanks for your understanding and for helping us shape the future of Paessler.

   Best regards,

   The Paessler Product Team

   Hi there,

   Thank you again for submitting your idea to Paessler. We truly appreciate you taking the time to share your feedback.

   After careful consideration by our team, we've decided to decline this idea at this time.

   Please note that we don't have plans to remove the Unknown state, as it is a fundamental part of PRTG's architecture.

   Down state occurs when PRTG successfully contacts the target device, but the monitored element is not functioning properly.

   Unknown state occurs when PRTG cannot retrieve any information about the sensor's current state, usually due to a disconnected probe or network issue.

   In your scenario (Down → Unknown → Down), what's happening is:

   1. Your sensor is genuinely down (device/interface issue)
   2. The network path fails (probe-to-device or probe-to-core connection)
   3. Sensor transitions to Unknown (PRTG cannot retrieve status)
   4. Connection restores
   5. Sensor returns to Down (original issue still exists)

   While we cannot disable the Unknown state,… more

2. Notify for hanging sensors

   it is possible that a system what to be monitored are still responding but are not any more running properly.

   For example, a system CPU is always changing, it is unusual that the CPU time is over many minutes constant at 19.0%. CPU load is always changing.

   It would be good to get from PRTG a notification if a usually changing sensor value delivers over a time a constant value.

   See attached, there is a running system where the CPU hangs on 19% over days.

   •  

   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

   1 comment  ·  Delete…  ·  Admin →
   Declined  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

   Non-response, please comment to re-open.

3. Sensorgruppen so zu erstellen Benachrichtigungen

   Hallo, ich bin neu in der Verwendung von PRTG in der Enterprise-Version.

   Ich weiß nicht, ob es möglich ist, Sensorgruppen so zu erstellen, dass Benachrichtigungen an die jeweiligen Gruppen gesendet werden.
   Zum Beispiel: Für Sensoren, die mit Linux zu tun haben, sollen die Benachrichtigungen an die zuständigen Personen gehen. Aber auf demselben Server gibt es auch Sensoren, die dem Eigentümer der Anwendung gehören, wie zum Beispiel Oracle.
   Wenn ich für jeden einzelnen Sensor die Benachrichtigungen bearbeiten muss, ist das unverständlich – ich spreche hier von tausenden von Sensoren, nicht nur von einer kleinen Anzahl.

   Falls PRTG eine solche Gruppierungsoption bietet, wäre das sehr gut. Falls nicht, bitte ich Sie dringend, eine solche Funktion zu entwickeln.

   Hallo, ich bin neu in der Verwendung von PRTG in der Enterprise-Version.

   Ich weiß nicht, ob es möglich ist, Sensorgruppen so zu erstellen, dass Benachrichtigungen an die jeweiligen Gruppen gesendet werden.
   Zum Beispiel: Für Sensoren, die mit Linux zu tun haben, sollen die Benachrichtigungen an die zuständigen Personen gehen. Aber auf demselben Server gibt es auch Sensoren, die dem Eigentümer der Anwendung gehören, wie zum Beispiel Oracle.
   Wenn ich für jeden einzelnen Sensor die Benachrichtigungen bearbeiten muss, ist das unverständlich – ich spreche hier von tausenden von Sensoren, nicht nur von einer kleinen Anzahl.

   Falls PRTG eine solche Gruppierungsoption bietet,… 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

   0 comments  ·  Delete…  ·  Admin →
   Declined  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

   Hi there,

   Thank you again for submitting your idea to Paessler. We truly appreciate you taking the time to share your feedback.

   After careful consideration by our team, we've decided to decline this idea at this time. This decision was made based on several factors, which may include:

   • It doesn't align with our current product roadmap or strategic priorities.
   • The resources required for implementation outweigh the current projected benefits for our user base.
   • There are technical limitations that prevent us from moving forward.
   • A similar feature is already available or planned in a different way.

   While this particular idea won't be moving forward, please don't be discouraged! Your input is incredibly valuable, and we encourage you to continue sharing your thoughts and ideas with us.

   Thanks for your understanding and for helping us shape the future of Paessler.

   Best regards,

   The Paessler Product Team