44 results found

1. Dynamic Interface Naming with ifIndex-Based Port Identification for SNMP Traffic Sensors

   As a Network Engineer, I want PRTG SNMP Traffic sensors to dynamically update interface descriptors (ifAlias, ifDesc, ifName) on every scanning interval while using ifIndex as the primary immutable identifier for port identification, so that sensor names remain accurate and searchable when network device interface descriptions are changed through configuration management.

   In cases where ifAlias, ifDesc, and ifName are used in port name templates, PRTG SNMP Traffic sensors should always pull these values and update them.

   ifIndex should be used by default to identify the ports and the other OIDs should be used as dynamically updating fields on every scanning interval.

   To have the flexibility for port identification other than ifIndex such as ifName, ifAlias, ifDesc, etc. then whichever OID is selected for port identification should be considered immutable. If the OID used for port identification cannot be found then the simple solution is to return an error.

   There are users who rely on PRTG to dynamically update the sensor names when the descriptions are reconfigured on the device. By not implementing in this way, there is a possibility for error by having outdated and mislabeled interfaces.

   As a Network Engineer, I want PRTG SNMP Traffic sensors to dynamically update interface descriptors (ifAlias, ifDesc, ifName) on every scanning interval while using ifIndex as the primary immutable identifier for port identification, so that sensor names remain accurate and searchable when network device interface descriptions are changed through configuration management.

   In cases where ifAlias, ifDesc, and ifName are used in port name templates, PRTG SNMP Traffic sensors should always pull these values and update them.

   ifIndex should be used by default to identify the ports and the other OIDs should be used as dynamically updating fields on every scanning… more

   13 votes

   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

   4 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
   Gathering Feedback  ·  AdminBenjamin Hackenberg (Admin, Paessler) responded

   Hi there,

   
   

   Great news! Your idea has been approved and moved to the next stage on Paessler.

   
   

   Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

   
   

   Here's how you can help:

   • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
   • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
   • Engage with comments: Respond to questions and suggestions from other users.

   
   

   The more engagement your idea receives, the better its chances of being fully implemented.

   
   

   Thanks for your continued collaboration in making Paessler even better!

   
   

   Best regards,

   The Paessler Product Team

2. Cisco ACI sensor

   As an Enterprise Network Administrator managing Cisco ACI infrastructure I want a dedicated Cisco ACI sensor in PRTG so that I can monitor the health, performance, and status of my Application Centric Infrastructure fabric without needing separate monitoring tools or complex custom scripts.

   Background:
   With the increasing adoption of software-defined networking and the complexity of modern data center environments, customers using Cisco ACI need comprehensive monitoring capabilities. Currently, monitoring ACI requires either expensive third-party tools, custom API integrations, or basic SNMP monitoring that misses critical ACI-specific metrics like fabric health scores, policy compliance, and tenant-specific performance data.

   6 votes

   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 →
   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
   Gathering Feedback  ·  AdminJörg Hollerith (Product Manager, Paessler) responded

   Hi there,

   
   

   Great news! Your idea has been approved and moved to the next stage on Paessler.

   
   

   Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

   
   

   Here's how you can help:

   • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
   • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
   • Engage with comments: Respond to questions and suggestions from other users.

   
   

   The more engagement your idea receives, the better its chances of being fully implemented.

   
   

   Thanks for your continued collaboration in making Paessler even better!

   
   

   Best regards,

   The Paessler Product Team

3. Expand SSL Certificate Monitoring Beyond HTTPS

   As a PRTG network administrator, I want to monitor SSL certificates for both HTTPS and MS SQL Server connections, so that I can proactively manage certificate expiration across all critical services without relying on complex external scripts.

   Since the current SSL Certificate is only for web (HTTPS) ports, it might be useful to update the name to "HTTPS SSL Certificate".

   Within the scope of MS SQL Server's connection SSL Certificate for the 1433 port, it will be useful to provide a way to monitor the certificate's expiry date. There is a number of pages with Python scripts that will pull the certificate, but to wire that into PRTG through a power shell script adds to many moving parts.

   As a PRTG network administrator, I want to monitor SSL certificates for both HTTPS and MS SQL Server connections, so that I can proactively manage certificate expiration across all critical services without relying on complex external scripts.

   Since the current SSL Certificate is only for web (HTTPS) ports, it might be useful to update the name to "HTTPS SSL Certificate".

   Within the scope of MS SQL Server's connection SSL Certificate for the 1433 port, it will be useful to provide a way to monitor the certificate's expiry date. There is a number of pages with Python scripts that will pull… more

   3 votes

   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

   2 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
   Gathering Feedback  ·  AdminIsidora Jeremic (Admin, Paessler) responded

   Hi there,

   
   

   Great news! Your idea has been approved and moved to the next stage on Paessler.

   
   

   Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

   
   

   Here's how you can help:

   • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
   • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
   • Engage with comments: Respond to questions and suggestions from other users.

   
   

   The more engagement your idea receives, the better its chances of being fully implemented.

   
   

   Thanks for your continued collaboration in making Paessler even better!

   
   

   Best regards,

   The Paessler Product Team

4. Enable PowerShell 7 Support for PRTG Custom Sensors

   As a Systems Engineer/IT Administrator, I want to use PowerShell 7 as the execution environment for PRTG custom sensors so that I can leverage modern PowerShell features, improve script performance, and eliminate compatibility workarounds in my monitoring solutions.

   8 votes

   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 →
   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
   Gathering Feedback  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

   Hi there,

   
   

   Great news! Your idea has been approved and moved to the next stage on Paessler.

   
   

   Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

   
   

   Here's how you can help:

   • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
   • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
   • Engage with comments: Respond to questions and suggestions from other users.

   
   

   The more engagement your idea receives, the better its chances of being fully implemented.

   
   

   Thanks for your continued collaboration in making Paessler even better!

   
   

   Best regards,

   The Paessler Product Team

5. Add "Warning Duration" to Sensor Data (API & UI) to Identify Long-Standing Warning States

   Currently, PRTG does not provide a way to determine how long a sensor has been in a warning state. This makes it difficult to distinguish between sensors that just entered a warning state and those that have been generating warnings for extended periods (hours, days, or weeks).

   Feature Request:
   Please add warning state duration information to PRTG with the following components:

   API Access (Most Important):
   - Add a "warningduration" or "timeincurrentstate" field to the sensor API endpoints
   - Enable filtering/querying sensors by warning duration via API parameters
   - This would allow for automated reporting and custom monitoring solutions

   User Interface:
   - Display warning duration as an additional detail line in sensor status data in the sensor overview (right list)
   - Add a "Warning Duration" or "Time in Warning State" column option
   - Enable filtering sensors by warning duration (e.g., "in warning for >24 hours", ">7 days", etc.)
   - Allow sorting sensors by how long they have been in their current warning state

   Use Case & Benefits:
   This feature would help identify "noisy" sensors that consistently remain in warning states without escalating to error or returning to normal. These sensors often indicate:
   - Thresholds that need adjustment
   - Non-critical issues that should be addressed but get overlooked
   - Devices that require maintenance or replacement
   - Sensors that may need to be reconfigured or paused

   By easily identifying long-standing warnings (especially via API for automated workflows), administrators can prioritize cleanup efforts, reduce alert fatigue, and maintain a cleaner, more actionable monitoring environment.

   Currently, PRTG does not provide a way to determine how long a sensor has been in a warning state. This makes it difficult to distinguish between sensors that just entered a warning state and those that have been generating warnings for extended periods (hours, days, or weeks).

   Feature Request:
   Please add warning state duration information to PRTG with the following components:

   API Access (Most Important):
   - Add a "warningduration" or "timeincurrentstate" field to the sensor API endpoints
   - Enable filtering/querying sensors by warning duration via API parameters
   - This would allow for automated reporting and custom… more

   3 votes

   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 →
   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
   Gathering Feedback  ·  AdminIsidora Jeremic (Admin, Paessler) responded

   Hi there,

   
   

   Great news! Your idea has been approved and moved to the next stage on Paessler.

   
   

   Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

   
   

   Here's how you can help:

   • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
   • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
   • Engage with comments: Respond to questions and suggestions from other users.

   
   

   The more engagement your idea receives, the better its chances of being fully implemented.

   
   

   Thanks for your continued collaboration in making Paessler even better!

   
   

   Best regards,

   The Paessler Product Team

6. Enable receiving SNMP Traps v3

   As a PRTG admin I would like to collect SNMP v3 traps from my devices that support this extra security level. My company and/or customers demand this security step in order to be 100% compliant.

   Affected Application
   PRTG // PRTG Network Monitor // Sensors and Probe

   How does this improve your daily work?
   Hi we got several requests from customers who want to receive SNMPv3 Traps in PRTG.
   At the moment only v1 and v2c traps are possible to be received.

   Our customers request these so to get the software 100% BSI-compliant.
   Otherwise they're refraining from procuring the tool at this stage.

   How important is this to you?
   High - Would really improve my work

   Usage Frequency
   Daily

   As a PRTG admin I would like to collect SNMP v3 traps from my devices that support this extra security level. My company and/or customers demand this security step in order to be 100% compliant.

   Affected Application
   PRTG // PRTG Network Monitor // Sensors and Probe

   How does this improve your daily work?
   Hi we got several requests from customers who want to receive SNMPv3 Traps in PRTG.
   At the moment only v1 and v2c traps are possible to be received.

   Our customers request these so to get the software 100% BSI-compliant.
   Otherwise they're refraining from procuring the tool at… more

   9 votes

   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

   2 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
   Gathering Feedback  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

   
   

7. Enhanced SNMP Interface Speed Monitoring with Built-in ifSpeed Channels

   As a Network Engineer, I want to monitor interface speeds (ifSpeed) as additional channels in SNMP Traffic sensors so that I can detect speed mismatches, auto-negotiation failures, and hardware issues without creating multiple custom sensors for each interface.

   6 votes

   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 →
   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
   Gathering Feedback  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

   Hi there,

   
   

   Great news! Your idea has been approved and moved to the next stage on Paessler.

   
   

   Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

   
   

   Here's how you can help:

   • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
   • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
   • Engage with comments: Respond to questions and suggestions from other users.

   
   

   The more engagement your idea receives, the better its chances of being fully implemented.

   
   

   Thanks for your continued collaboration in making Paessler even better!

   
   

   Best regards,

   The Paessler Product Team

8. WMI Service Group Sensor

   As a systems engineer, I want to monitor groups of related Windows services in a single sensor so that I can quickly identify if any critical service group is not running properly without having to create and manage multiple individual service sensors.
   Examples:
   - services set with "automatic start"
   - multiple services with a specific name in it (e.g. all backup services)

   4 votes

   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 →
   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
   Gathering Feedback  ·  AdminIsidora Jeremic (Admin, Paessler) responded

   Hi there,

   
   

   Great news! Your idea has been approved and moved to the next stage on Paessler.

   
   

   Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

   
   

   Here's how you can help:

   • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
   • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
   • Engage with comments: Respond to questions and suggestions from other users.

   
   

   The more engagement your idea receives, the better its chances of being fully implemented.

   
   

   Thanks for your continued collaboration in making Paessler even better!

   
   

   Best regards,

   The Paessler Product Team

9. Turn two devices into one - unifying PRTG device credential

   As a system administrator, I would like my physical devices to be represented in PRTG by a single virtual device in the UI to make things less confusing for me and my colleagues. Unfortunately, for certain devices and sensor technologies (MQTT, controller-managed devices), I need to create a second device in order to specify the address of the MQTT Broker or other "central" controller for sensor queries. Ideally, PRTG would allow the address of a device's controller to be defined in it's settings so that only one device is sufficient. Having one physical device mapped to one PRTG device would give me a better overview of my IT infrastructure.

   As a system administrator, I would like my physical devices to be represented in PRTG by a single virtual device in the UI to make things less confusing for me and my colleagues. Unfortunately, for certain devices and sensor technologies (MQTT, controller-managed devices), I need to create a second device in order to specify the address of the MQTT Broker or other "central" controller for sensor queries. Ideally, PRTG would allow the address of a device's controller to be defined in it's settings so that only one device is sufficient. Having one physical device mapped to one PRTG device would… more

   6 votes

   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 →
   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
   Gathering Feedback  ·  AdminJörg Hollerith (Product Manager, Paessler) responded

   Hi there,

   
   

   Great news! Your idea has been approved and moved to the next stage on Paessler.

   
   

   Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

   
   

   Here's how you can help:

   • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
   • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
   • Engage with comments: Respond to questions and suggestions from other users.

   
   

   The more engagement your idea receives, the better its chances of being fully implemented.

   
   

   Thanks for your continued collaboration in making Paessler even better!

   
   

   Best regards,

   The Paessler Product Team

10. Auto-Adaptive PRTG Sensors for Device Configuration Changes

    As a PRTG administrator managing dynamic IT/OT infrastructure, I want PRTG sensors to automatically adapt to device configuration changes (such as volume label modifications or disk capacity expansions) by using persistent hardware identifiers, so that I can maintain continuous monitoring without sensor failures, avoid losing historical data, and reduce manual maintenance overhead when routine infrastructure changes occur.

    When certain device-side properties change — such as a drive’s volume label or storage size — PRTG sensors (e.g., Disk Free Sensor) often fail, even though the hardware itself remains the same. For example: If the volume label of a hard drive changes, the sensor enters an error state and cannot be repaired. If the disk capacity is increased (e.g., resizing or expanding a virtual disk), the sensor fails even though the drive’s serial number remains unchanged.

    Currently, the only workaround is to delete and recreate the sensor, which results in loss of historical data and unnecessary maintenance overhead. I propose adding a feature that enables automatic sensor re-binding based on unique device identifiers (such as the disk serial number or hardware ID). This would allow PRTG to recognize that it’s still the same device, update the changed attributes dynamically, and continue monitoring without interruption.

    As a PRTG administrator managing dynamic IT/OT infrastructure, I want PRTG sensors to automatically adapt to device configuration changes (such as volume label modifications or disk capacity expansions) by using persistent hardware identifiers, so that I can maintain continuous monitoring without sensor failures, avoid losing historical data, and reduce manual maintenance overhead when routine infrastructure changes occur.

    When certain device-side properties change — such as a drive’s volume label or storage size — PRTG sensors (e.g., Disk Free Sensor) often fail, even though the hardware itself remains the same. For example: If the volume label of a hard drive changes,… more

    3 votes

    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 →
    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
    Gathering Feedback  ·  AdminBenjamin Hackenberg (Admin, Paessler) responded

    Hi there,

    
    

    Great news! Your idea has been approved and moved to the next stage on Paessler.

    
    

    Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

    
    

    Here's how you can help:

    • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
    • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
    • Engage with comments: Respond to questions and suggestions from other users.

    
    

    The more engagement your idea receives, the better its chances of being fully implemented.

    
    

    Thanks for your continued collaboration in making Paessler even better!

    
    

    Best regards,

    The Paessler Product Team

11. Scheduled tasks sensor

    As a Windows Admin using PRTG I need to be able to monitor my business processes running as scheduled tasks so that I can ensure my business processes are executing.

    Today this is done via external tools and managing them is not ideal. There was a deprecated sensor for this but nothing really took its place. See https://www.reddit.com/r/prtg/comments/1lececg/if_youre_using_scheduledtask2xmlexe_from_prtg/

    7 votes

    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 →
    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
    Gathering Feedback  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

    Hi there,

    
    

    Great news! Your idea has been approved and moved to the next stage on Paessler.

    
    

    Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

    
    

    Here's how you can help:

    • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
    • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
    • Engage with comments: Respond to questions and suggestions from other users.

    
    

    The more engagement your idea receives, the better its chances of being fully implemented.

    
    

    Thanks for your continued collaboration in making Paessler even better!

    
    

    Best regards,

    The Paessler Product Team

12. Docker sensor

    As a sysadmin or developer I would like to get metrics on the health and performance of the containers within a single Docker runtime so that I can monitor the health of the containers.

    9 votes

    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 →
    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
    Gathering Feedback  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

    Hi there,

    
    

    Great news! Your idea has been approved and moved to the next stage on Paessler.

    
    

    Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

    
    

    Here's how you can help:

    • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
    • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
    • Engage with comments: Respond to questions and suggestions from other users.

    
    

    The more engagement your idea receives, the better its chances of being fully implemented.

    
    

    Thanks for your continued collaboration in making Paessler even better!

    
    

    Best regards,

    The Paessler Product Team

13. SNMP Interface Traffic Sensor with ifLastChange Channel for Interface Flapping Detection

    As a Network Engineer managing critical network infrastructure, I want the SNMP Interface Traffic sensor to include an 'Interface Last Change' channel that monitors the ifLastChange timestamp, so that I can detect interface flapping and instability without having to create separate custom sensors for each interface or rely on SNMP traps.

    4 votes

    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 →
    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
    Gathering Feedback  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

    Hi there,

    
    

    Great news! Your idea has been approved and moved to the next stage on Paessler.

    
    

    Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

    
    

    Here's how you can help:

    • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
    • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
    • Engage with comments: Respond to questions and suggestions from other users.

    
    

    The more engagement your idea receives, the better its chances of being fully implemented.

    
    

    Thanks for your continued collaboration in making Paessler even better!

    
    

    Best regards,

    The Paessler Product Team

14. Add support for SNMPv3 authNoPriv mode in PRTG

    As a network engineer managing devices from ISPs and vendors with restricted SNMP configurations, I want PRTG to support SNMPv3 authNoPriv mode (authentication without encryption) so that I can monitor critical infrastructure devices that only allow this security level.

    Currently, PRTG only supports SNMPv3 with authPriv (authentication + encryption). Many providers, e.g. Telekom, only offer SNMPv3 in authNoPriv mode.

    Example configuration (as provided by Telekom, not changeable):
    Mode: authNoPriv
    Authentication Protocol: MD5
    Privacy (Encryption): None

    Since PRTG does not support authNoPriv, monitoring such devices is currently impossible.

    3 votes

    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 →
    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
    Gathering Feedback  ·  AdminIsidora Jeremic (Admin, Paessler) responded

    Hi there,

    
    

    Great news! Your idea has been approved and moved to the next stage on Paessler.

    
    

    Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

    
    

    Here's how you can help:

    • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
    • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
    • Engage with comments: Respond to questions and suggestions from other users.

    
    

    The more engagement your idea receives, the better its chances of being fully implemented.

    
    

    Thanks for your continued collaboration in making Paessler even better!

    
    

    Best regards,

    The Paessler Product Team

15. Kubernetes Sensor

    As a DevOps Engineer, I need a native PRTG sensor to monitor the health and performance of my custom applications running in Kubernetes, so that I can gain immediate, centralized visibility into their operational status, proactively identify issues at the cluster, pod, and application level, and ensure the continuous availability and performance of my services.

    1. Kubernetes-Aware Monitoring:

       • Ability to target and understand applications deployed via Kubernetes constructs (e.g., Deployments, Pods, Namespaces).
       • Provide insights into the overall health and status of application deployments (e.g., how many instances are running vs. expected).
       • Report on the status and lifecycle of individual application pods and containers (e.g., running, restarting, unhealthy probes).

    2. Comprehensive Application Metrics:

       • Collect vital resource usage metrics for application containers (CPU, memory).
       • Monitor the responsiveness and availability of key application services or APIs exposed within Kubernetes.
       • Track internal application health indicators like queue depths, active connections, or pending tasks.
       • Gather application-specific error counts or critical event notifications.

    3. Clear & Actionable Insights:

       • Present all collected data as distinct, clearly labeled channels within PRTG (e.g., "Deployment Status," "Pod Restarts," "API Latency," "Application Errors").
       • Automatically apply sensible default thresholds (warning/error) to these channels, which can be easily adjusted.
       • Provide clear, descriptive messages when an application or its underlying Kubernetes components are in a warning or error state, helping to quickly pinpoint the problem.

    4. Easy Setup & Configuration:

       • Be discoverable and configurable directly within the standard PRTG web interface.
       • Allow straightforward selection of which Kubernetes namespaces, deployments, or application types to monitor.
       • Require minimal setup effort to connect to the Kubernetes cluster.

    5. Reliability & Performance:

       • Operate efficiently without significantly impacting the performance of the monitored Kubernetes cluster or the PRTG server itself.
       • Provide consistent and reliable data collection to prevent monitoring blind spots.

    As a DevOps Engineer, I need a native PRTG sensor to monitor the health and performance of my custom applications running in Kubernetes, so that I can gain immediate, centralized visibility into their operational status, proactively identify issues at the cluster, pod, and application level, and ensure the continuous availability and performance of my services.

    1. Kubernetes-Aware Monitoring:

       • Ability to target and understand applications deployed via Kubernetes constructs (e.g., Deployments, Pods, Namespaces).
       • Provide insights into the overall health and status of application deployments (e.g., how many instances are running vs. expected).
       • Report on the status and lifecycle of individual application pods… more
    5 votes

    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 →
    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
    Gathering Feedback  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

    Hi there,

    
    

    Great news! Your idea has been approved and moved to the next stage on Paessler.

    
    

    Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

    
    

    Here's how you can help:

    • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
    • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
    • Engage with comments: Respond to questions and suggestions from other users.

    
    

    The more engagement your idea receives, the better its chances of being fully implemented.

    
    

    Thanks for your continued collaboration in making Paessler even better!

    
    

    Best regards,

    The Paessler Product Team

16. Enhance RADIUS v2 Sensor to comply with RFC 3579 Message-Authenticator

    As a Network Engineer, I want the RADIUS v2 sensor to support RFC 3579 Message-Authenticator validation so that I can monitor RADIUS servers with enhanced security and ensure authentication packet integrity in my network infrastructure. The client (PRTG Sensor) computes the hash (HMAC-MD5) from its own packet and then adds the attribute as a signature to the request. This is required for secure implementations of RADIUS.

    https://www.cisco.com/c/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/118673-technote-radius-00.html

    3 votes

    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 →
    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
    Gathering Feedback  ·  AdminIsidora Jeremic (Admin, Paessler) responded

    Hi there,

    
    

    Great news! Your idea has been approved and moved to the next stage on Paessler.

    
    

    Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

    
    

    Here's how you can help:

    • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
    • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
    • Engage with comments: Respond to questions and suggestions from other users.

    
    

    The more engagement your idea receives, the better its chances of being fully implemented.

    
    

    Thanks for your continued collaboration in making Paessler even better!

    
    

    Best regards,

    The Paessler Product Team

17. XOA/XCP-ng Sensor

    As an IT Infrastructure Manager migrating from VMware to XCP-ng, I want native PRTG sensors for XCP-ng hosts and XOA management so that I can maintain comprehensive virtualization monitoring without losing visibility or requiring custom development work during and after migration.

    2 votes

    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

    2 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
    Gathering Feedback  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

    I have a couple of additional questions to make this more solid as we collect votes on this request :

    
    

    1. Which specific XCP-ng metrics are most critical for your monitoring needs?
    2. Do you need XOA-specific monitoring (backup jobs, user sessions) or primarily hypervisor metrics?

    
    

    Great news! Your idea has been approved and moved to the next stage on Paessler.

    
    

    Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

    
    

    Here's how you can help:

    • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
    • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
    • Engage with comments: Respond to questions and suggestions from other users.

    
    

    The more engagement your idea receives, the better its chances of being fully implemented.

    
    

    Thanks for your continued collaboration in making Paessler even better!

    
    

    Best regards,

    The Paessler Product Team

    I have a couple of additional questions to make this more solid as we collect votes on this request :

    
    

    1. Which specific XCP-ng metrics are most critical for your monitoring needs?
    2. Do you need XOA-specific monitoring (backup jobs, user sessions) or primarily hypervisor metrics?

    
    

    Great news! Your idea has been approved and moved to the next stage on Paessler.

    
    

    Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

    
    

    Here's how you can help:

    • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
    • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
    • Engage with comments: Respond to questions and suggestions from other users.

    
    

    The more engagement… more

18. Support for Monitoring NetApp ASA r2 and AFX Systems in PRTG

    As a Storage Administrator
    I want PRTG to support monitoring of the new NetApp ONTAP-based systems ASA r2 and AFX
    So that I can ensure full visibility and performance tracking of these devices within our existing monitoring environment.

    Context & Details
    NetApp recently introduced two new ONTAP-based platforms:

    ASA r2: All-Flash SAN Array optimized for block storage.
    AFX: High-performance NAS/S3 system designed for AI/ML workloads.

    Both systems leverage the ONTAP REST API but include specific changes and new endpoints:

    ASA r2 introduces endpoints like /api/storage/storage-units and /api/storage/block-volumes for LUNs and NVMe namespaces, and recommends OAuth 2.0 for authentication.

    AFX removes certain ONTAP endpoints (e.g., MetroCluster, SAN) and focuses on NFS, SMB, and S3 protocols.

    Reference: ASA r2 REST API Documentation - https://docs.netapp.com/us-en/asa-r2/learn-more/rest-api-support.html

    Why This Matters
    Current PRTG NetApp v2 sensors support ONTAP REST API starting from version 9.6, but these new platforms have different API structures and performance metric limitations (e.g., ASA r2 does not support RestPerf, only KeyPerf/StatPerf). Without native support, monitoring these systems requires custom REST sensors, which is less efficient and harder to maintain.

    As a Storage Administrator
    I want PRTG to support monitoring of the new NetApp ONTAP-based systems ASA r2 and AFX
    So that I can ensure full visibility and performance tracking of these devices within our existing monitoring environment.

    Context & Details
    NetApp recently introduced two new ONTAP-based platforms:

    ASA r2: All-Flash SAN Array optimized for block storage.
    AFX: High-performance NAS/S3 system designed for AI/ML workloads.

    Both systems leverage the ONTAP REST API but include specific changes and new endpoints:

    ASA r2 introduces endpoints like /api/storage/storage-units and /api/storage/block-volumes for LUNs and NVMe namespaces, and recommends OAuth 2.0 for authentication.

    AFX removes… more

    2 votes

    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 →
    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
    Gathering Feedback  ·  AdminBenjamin Hackenberg (Admin, Paessler) responded

    Hi there,

    
    

    Great news! Your idea has been approved and moved to the next stage on Paessler.

    
    

    Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

    
    

    Here's how you can help:

    • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
    • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
    • Engage with comments: Respond to questions and suggestions from other users.

    
    

    The more engagement your idea receives, the better its chances of being fully implemented.

    
    

    Thanks for your continued collaboration in making Paessler even better!

    
    

    Best regards,

    The Paessler Product Team

19. Enhanced Windows Update Sensor with Time-Based Criticality Tracking

    As a System Administrator responsible for security compliance, I want to see how long Windows updates of different criticality levels have been available so that I can prioritize patching efforts based on both severity and exposure duration, ensuring compliance requirements are met and security risks are minimized.

    3 votes

    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 →
    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
    Gathering Feedback  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

    Hi there,

    
    

    Great news! Your idea has been approved and moved to the next stage on Paessler.

    
    

    Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

    
    

    Here's how you can help:

    • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
    • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
    • Engage with comments: Respond to questions and suggestions from other users.

    
    

    The more engagement your idea receives, the better its chances of being fully implemented.

    
    

    Thanks for your continued collaboration in making Paessler even better!

    
    

    Best regards,

    The Paessler Product Team

20. Stratum level channel for the SNTP Sensor

    As a sysadmin I would like to see the stratum level as integer in the SNTP sensor. That way I can set limits/alerts on it when the required stratum level is not reached.
    
    The correct stratum level is important for synchronisation of time on different machines.

    5 votes

    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 →
    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
    Gathering Feedback  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

    Hi there,

    
    

    Great news! Your idea has been approved and moved to the next stage on Paessler.

    
    

    Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.

    
    

    Here's how you can help:

    • Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
    • Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
    • Engage with comments: Respond to questions and suggestions from other users.

    
    

    The more engagement your idea receives, the better its chances of being fully implemented.

    
    

    Thanks for your continued collaboration in making Paessler even better!

    
    

    Best regards,

    The Paessler Product Team