64 results found

1. Native Veeam Backup & Replication API Integration for PRTG Backup Job Monitoring (Without Enterprise Manager)

   As a Systems Engineer managing my organization's IT infrastructure with PRTG, I want PRTG to monitor Veeam Backup & Replication job statuses by connecting directly to the Veeam B&R REST API (v13+), so that I can monitor backup jobs without requiring a Veeam Enterprise Manager license or a portal administrator account, reducing both licensing costs and security exposure.

   The current Veeam Backup Job Status (and Advanced) sensors still require and use Veeam Enterprise Manager (and require portal administrator role).

   Would be great to refactor or build new sensors to use/connect directly to the Veeam B&R server instead of the Veeam Enterprise Manager as V13 provide API endpoint.

   This will provide Veeam Backup job monitoring to PRTG customers who don't have any Enterprise Manager Console license and for a security improvement, will not require an admin user for this monitoring purpose.

   As a Systems Engineer managing my organization's IT infrastructure with PRTG, I want PRTG to monitor Veeam Backup & Replication job statuses by connecting directly to the Veeam B&R REST API (v13+), so that I can monitor backup jobs without requiring a Veeam Enterprise Manager license or a portal administrator account, reducing both licensing costs and security exposure.

   The current Veeam Backup Job Status (and Advanced) sensors still require and use Veeam Enterprise Manager (and require portal administrator role).

   Would be great to refactor or build new sensors to use/connect directly to the Veeam B&R server instead of the Veeam… more

   20 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

   Gathering Feedback  ·  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. Native Azure Monitoring Sensors at AutoMonX Parity

   As a PRTG user monitoring an Azure environment,
   I want native Azure sensors in PRTG that provide the same depth and coverage as those offered by AutoMonX,
   so that I can monitor my Azure infrastructure comprehensively without relying on a third-party solution, incurring additional costs, or managing a separate contract.

   Background / Context:
   PRTG's current Azure-related sensors cover only basic functionality. While AutoMonX (automonx.com/azure) fills this gap on a commercial basis, prospects and customers increasingly expect a native, fully integrated solution from PRTG itself — one that requires no additional vendor relationship or cost.

   7 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

   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

3. Migration-Aware Proxmox VE VM Monitoring: Automatically Track VMs Across Cluster Nodes

   As a Systems Engineer running a Proxmox VE cluster,
   I want PRTG's Proxmox VM monitoring to automatically detect and follow a virtual machine when it migrates to a different cluster node,
   so that I receive accurate up/down status for the VM (including VMs I cannot monitor directly, e.g., in a DMZ) without false errors or manual sensor reconfiguration after routine host patching and migrations.

   4 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

4. 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

   28 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

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

5. Built-in Migration from Old SNMP Sensors to Their v2 Successors with Historical Data Retention

   As a Systems Engineee,
   I want a built-in/ automatic migration from existing legacy SNMP sensors to their newer v2 sensor equivalents,
   so that I can adopt the improved sensor types without manually recreating hundreds of sensors and without losing my historical monitoring data, alerts, and configurations.

   13 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

   Gathering Feedback  ·  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

6. SNMP Custom Table Sensor: Enable String Value Handling in Channels

   As a Network Engineer monitoring multi-vendor network infrastructure,
   I want the SNMP Custom Table sensor to support string value handling in its channels (e.g., mapping strings to sensor states or displaying them in the sensor message),
   so that I can monitor all relevant data from SNMP tables - including string-based status fields, names, and descriptors, without needing to create individual string sensors or custom scripts for each OID.

   Background:
   In SNMP Custom Table sensors, it is currently not possible to evaluate string returns within channel strings. The user considers this a notable gap, because string returns are very common in SNMP-based network monitoring and not an exception.

   Example OIDs / vendor context:
   Aruba example table OIDs: .1.3.6.1.4.1.47196.4.1.1.3.15.1.2
   Aruba example table OIDs: .1.3.6.1.4.1.47196.4.1.1.3.15.1.4
   The Aruba OIDs show that many values are returned as strings rather than purely numeric values. This is standard practice in SNMP network monitoring.

   As a Network Engineer monitoring multi-vendor network infrastructure,
   I want the SNMP Custom Table sensor to support string value handling in its channels (e.g., mapping strings to sensor states or displaying them in the sensor message),
   so that I can monitor all relevant data from SNMP tables - including string-based status fields, names, and descriptors, without needing to create individual string sensors or custom scripts for each OID.

   Background:
   In SNMP Custom Table sensors, it is currently not possible to evaluate string returns within channel strings. The user considers this a notable gap, because string returns are very common in… more

   5 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

   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

7. Native Nginx Status Sensor

   As a Systems Engineer running nginx as my web server, I want a dedicated PRTG sensor that reads nginx's built-in status page and turns it into real-time channels for active connections, request throughput, connection states, and dropped connections, so that I can monitor my web server's actual load and health and get alerted before it starts refusing traffic.

   5 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

   Gathering Feedback  ·  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

8. MQTT Sensors: Support the full MQTT QoS spectrum (QoS 0 / 1 / 2), not only QoS 2

   Problem / Current Limitation:
   PRTG's MQTT sensors currently hard-require QoS 2 as a fixed, non-configurable part of their implementation — none of PRTG's available MQTT sensor types offer QoS 0 or QoS 1 as an alternative. QoS 0, 1, and 2 are all standard, valid delivery levels defined by the MQTT protocol itself — a broker or service that only offers QoS 0/1 is not doing anything non-standard or unusual, it's simply choosing a different (and very common) point on the QoS spectrum. By hard-coding QoS 2 across the board, PRTG effectively excludes any MQTT broker or managed service that doesn't implement QoS 2, regardless of how widely used that service is.

   Concrete example / Business case:
   AWS IoT Core — one of the most widely used managed MQTT broker services worldwide — only supports QoS 0 and QoS 1, and does not support QoS 2 at all. This isn't a niche or non-compliant setup; it's a deliberate, documented design choice by AWS and affects every AWS IoT Core customer trying to monitor via PRTG's MQTT sensors. In our case, we use AWS IoT Core (mTLS, port 8883) to collect MQTT telemetry from our self-developed Ticket Vending Machines (TVMs) — status, cabinet/climate, printer, flood, POS, PC, door, VoIP intercom, UPS, etc. — across 25+ MQTT sensors per site, and AWS IoT Core is a firm architectural commitment going forward. There is currently no sensor-side flag or workaround, and no alternative PRTG sensor type, that supports this natively.

   Without QoS 0/1 support, customers on any QoS-0/1-only broker are left with two unsatisfactory options: run an extra intermediary broker (e.g. Mosquitto, EMQX, HiveMQ) purely to translate QoS 2 down to QoS 1 — added infrastructure and an added point of failure for no functional benefit — or abandon PRTG for that telemetry and use other tooling instead.

   Requested change:
   Make the QoS level configurable (QoS 0 / 1 / 2) across PRTG's MQTT sensors, so they can negotiate whatever QoS level the target broker actually supports, instead of assuming QoS 2 is universal.

   Impact if implemented:
   Brings PRTG's MQTT sensors in line with the actual MQTT specification, removing an artificial compatibility gap. Benefits any customer connecting to a broker that doesn't offer QoS 2 — AWS IoT Core being the largest and most obvious example, but not the only one — without requiring extra bridging infrastructure.

   Problem / Current Limitation:
   PRTG's MQTT sensors currently hard-require QoS 2 as a fixed, non-configurable part of their implementation — none of PRTG's available MQTT sensor types offer QoS 0 or QoS 1 as an alternative. QoS 0, 1, and 2 are all standard, valid delivery levels defined by the MQTT protocol itself — a broker or service that only offers QoS 0/1 is not doing anything non-standard or unusual, it's simply choosing a different (and very common) point on the QoS spectrum. By hard-coding QoS 2 across the board, PRTG effectively excludes any MQTT broker or managed service that… more

   3 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

   Gathering Feedback  ·  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

9. Monitoring-status filter for SNMP interface selection when adding Traffic sensors

   As a Network Engineer responsible for switch and bandwidth monitoring,
   I want to filter the interface list in the SNMP sensor creation dialog by monitoring status — specifically to show only interfaces that do not yet have a sensor (and optionally hide those that do) —
   so that I can quickly identify and add recently connected or overlooked ports without manually cross-checking the full interface list against existing sensors, avoiding both wasted time and accidental duplicate sensors.

   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

10. Native F5 BIG-IP Sensors

    As a Network Engineer, I want native F5 BIG-IP sensors (BIG-IP 17.x): LTM Nodes, Pools, Pool Members, Virtual Servers, and System sensors (CPU, Interface, Disk, Cluster). These sensors must auto-discover objects and create channels dynamically.

    Customer Need:
    Native, out‑of‑the‑box PRTG sensors for F5 BIG‑IP devices, designed similarly to other vendor-specific sensor types (e.g., FortiGate, HPE, NetApp).
    These sensors should provide intelligent auto‑discovery and automatic channel creation, instead of requiring SNMP Custom sensors.

    We expect sensor types that automatically detect and monitor:

    A. LTM Object Sensors (from LOCAL-MIB)
    Each of these should be a dedicated native sensor type:

    F5 LTM Nodes Sensor
    F5 LTM Pools Sensor
    F5 LTM Pool Members Sensor
    F5 LTM Virtual Servers Sensor

    B. System Sensors (from SYSTEM-MIB)
    Native system-level sensors, similar to our existing CPU/Disk/Interface sensors:

    F5 System Interface Sensor
    F5 System CPU Sensor
    F5 System Cluster Status Sensor
    F5 System Disk Sensor

    As a Network Engineer, I want native F5 BIG-IP sensors (BIG-IP 17.x): LTM Nodes, Pools, Pool Members, Virtual Servers, and System sensors (CPU, Interface, Disk, Cluster). These sensors must auto-discover objects and create channels dynamically.

    Customer Need:
    Native, out‑of‑the‑box PRTG sensors for F5 BIG‑IP devices, designed similarly to other vendor-specific sensor types (e.g., FortiGate, HPE, NetApp).
    These sensors should provide intelligent auto‑discovery and automatic channel creation, instead of requiring SNMP Custom sensors.

    We expect sensor types that automatically detect and monitor:

    A. LTM Object Sensors (from LOCAL-MIB)
    Each of these should be a dedicated native sensor type:

    F5 LTM Nodes… more

    15 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

    Gathering Feedback  ·  3 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

11. VMware Snapshot Monitoring Sensor

    As an IT administrator managing VMware infrastructure, I would like a dedicated sensor to monitor virtual machine snapshots in PRTG, so that I can proactively detect and remediate snapshot-related issues before they cause performance degradation or storage outages.

    11 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

    Gathering Feedback  ·  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

12. 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

    15 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

    3 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

13. Enable Auto-Acknowledge for Ping v2 Sensor Alerts

    As an IT Infrastructure Manager managing a large-scale monitoring environment,
    I want the ability to enable automatic acknowledgment of alerts on Ping v2 sensors,
    so that I can use Ping sensors for lightweight availability tracking and state logging without being burdened by a high volume of alerts that require manual acknowledgment.

    Background:
    In the legacy Ping sensors, there was a feature that allowed automatic acknowledgment of alerts (auto-ack).
    We use Ping sensors across a large number of devices primarily for visibility. They act as a lightweight form of logging and state tracking.
    Notifications are still triggered as needed, but we do not require manual acknowledgment for every alert.
    Without auto-ack, managing a high volume of alerts becomes operationally heavy and reduces the usability of these sensors in our environment.

    As an IT Infrastructure Manager managing a large-scale monitoring environment,
    I want the ability to enable automatic acknowledgment of alerts on Ping v2 sensors,
    so that I can use Ping sensors for lightweight availability tracking and state logging without being burdened by a high volume of alerts that require manual acknowledgment.

    Background:
    In the legacy Ping sensors, there was a feature that allowed automatic acknowledgment of alerts (auto-ack).
    We use Ping sensors across a large number of devices primarily for visibility. They act as a lightweight form of logging and state tracking.
    Notifications are still triggered as needed, but we… more

    •  

    •  

    4 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

    In Progress  ·  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

14. 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.

    15 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

    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

15. 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

    12 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

    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

16. 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

    29 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

    8 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

17. Make PRTG's XML sensor interface parse real-world XML reliably and consistently

    As a Systems Engineer who builds custom integrations (e.g., wrapping NRPE/Nagios plugin output for PRTG via a web server),
    I want the XML processing of the HTTP Data Advanced sensor (and related advanced custom sensors) to behave like a real, standards-compliant XML parser — accepting comments, matching values to channels by name rather than position, and letting me explicitly designate the primary channel —
    so that I can generate sensor output from any standard tool or library (hash tables, XSLT, alphabetically sorted REST responses) without fragile ordering hacks, and get consistent results regardless of which sensor type consumes the data.

    Background:
    Trying to write a sensor that outputs XML demonstrated how badly designed the whole XML-processing really is:
    1) the parser does not recognize XML comments, so actually I would not call it XML parser at all
    2) the XML data model is just terrible (I named it "tag soup", because it doesn't really have a well-designed structure)
    3) Depending on the sensor being used, the same XML output is interpreted differently; for example only the HTTP Data Advanced can deduce the actual channel names without needing a mapfile on the server
    4) Even if the HTTP Data Advanced sensor can assign a name to a channel's value, the actual values are retrieved by position (it seems to me). So the order has to be the same all the time (bad if you collect your valuers in a hash table, for example)
    5) The HTTP Data Advanced sensor always assumes the first value is the most important one; bad if your sensor (REST server) sorts the labels alphabetically, just for example)

    Here's an example of some XML output that PRTG cannot handle:
    <?xml version="1.0" encoding="UTF-8"?>
    <!--MonitoringOutput v0.2 id=NRPE@local:checkload (PRTG.xsl v0.0.11)-->
    <Prtg>
    <!--Description: "/usr/lib/nagios/plugins/checknrpe" "-4" "-H" "localhost" "-c" "check_load"-->
    <!--Exit Code: 0-->
    <!--Info String: OK - load average: 0.21, 0.11, 0.04-->
    <!--Perf String: load1=0.210;10.000;15.000;0; load5=0.110;6.000;10.000;0; load15=0.040;5.000;8.000;0; -->
    <Text/>
    <Result>
    <Channel>load1</Channel>
    <Value>0.210</Value>
    <Float>1</Float>
    <!--DEBUG(1): (:10.000)-->
    <LimitMaxWarning>10.000</LimitMaxWarning>
    <!--DEBUG(1): (:15.000)-->
    <LimitMaxError>15.000</LimitMaxError>
    </Result>
    <Result>
    <Channel>load5</Channel>
    <Value>0.110</Value>
    <Float>1</Float>
    <!--DEBUG(1): (:6.000)-->
    <LimitMaxWarning>6.000</LimitMaxWarning>
    <!--DEBUG(1): (:10.000)-->
    <LimitMaxError>10.000</LimitMaxError>
    </Result>
    <Result>
    <Channel>load15</Channel>
    <Value>0.040</Value>
    <Float>1</Float>
    <!--DEBUG(1): (:5.000)-->
    <LimitMaxWarning>5.000</LimitMaxWarning>
    <!--DEBUG(1): (:8.000)-->
    <LimitMaxError>8.000</LimitMaxError>
    </Result>
    </Prtg>

    (As you can see I converted the output of an NRPE plugin to PTRG (using a HTTP server))

    As a Systems Engineer who builds custom integrations (e.g., wrapping NRPE/Nagios plugin output for PRTG via a web server),
    I want the XML processing of the HTTP Data Advanced sensor (and related advanced custom sensors) to behave like a real, standards-compliant XML parser — accepting comments, matching values to channels by name rather than position, and letting me explicitly designate the primary channel —
    so that I can generate sensor output from any standard tool or library (hash tables, XSLT, alphabetically sorted REST responses) without fragile ordering hacks, and get consistent results regardless of which sensor type consumes the data.

    … 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

    Gathering Feedback  ·  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

18. Modernized Citrix XenServer Sensors with TLS 1.2+ Support

    As a Systems Engineer responsible for virtualization infrastructure, I want PRTG's Citrix XenServer Host and Virtual Machine sensors to fully support TLS 1.2 or higher, so that I can monitor my XenServer hosts and VMs without weakening the hypervisor's security configuration or losing visibility as older TLS versions are deprecated.

    Background:
    The current Citrix sensors do not support TLS 1.2 or higher. Since older TLS versions are being phased out and not supported, the current sensors need to be updated, or new sensors need to be created.

    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

    Gathering Feedback  ·  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

19. Prevent Auto-Discovery from Creating a Ping v2 Sensor with Ping v1 Functionality

    As a Network Engineer managing devices discovered via PRTG auto-discovery,
    I want auto-discovery (including the default templates Generic Device (Ping Only) and Generic Device (SNMP Enabled)) to create ping sensors whose sensor type label matches their actual channel structure, settings, and documented functionality — i.e., a sensor labeled Ping v2 behaves as documented for Ping v2, or a sensor with Ping v1 behavior is labeled Ping v1,
    so that I can trust that sensors were created correctly, reliably filter and manage sensors by type, and avoid wasting time investigating "broken" sensors that are actually just mislabeled.

    Background:
    In PRTG 26.3.122.1665, when Auto-Discovery is performed using PRTG's default device templates (for example, Auto-Discovery without specifying a template, Generic Device (Ping Only), or Generic Device (SNMP Enabled)), a sensor is created whose sensor type is Ping v2.
    However, this sensor has the same channel structure and settings as the old Ping v1 sensor and only provides Ping v1 functionality.
    This can lead users to believe that the sensor was not created correctly or is broken because its sensor type is Ping v2, but it does not have the functionality or settings described for Ping v2 in the documentation.
    It also causes inconvenience when filtering sensors by sensor type, because these sensors are identified as Ping v2 even though they only have Ping v1 functionality.

    We request that the sensor type and its actual functionality be made consistent.
    Ideally:
    If Auto-Discovery creates a sensor with the Ping v2 sensor type, it should provide the actual Ping v2 functionality.
    If Auto-Discovery is intended to create a sensor with Ping v1 functionality, it should create the sensor with the Ping v1 sensor type.

    As a Network Engineer managing devices discovered via PRTG auto-discovery,
    I want auto-discovery (including the default templates Generic Device (Ping Only) and Generic Device (SNMP Enabled)) to create ping sensors whose sensor type label matches their actual channel structure, settings, and documented functionality — i.e., a sensor labeled Ping v2 behaves as documented for Ping v2, or a sensor with Ping v1 behavior is labeled Ping v1,
    so that I can trust that sensors were created correctly, reliably filter and manage sensors by type, and avoid wasting time investigating "broken" sensors that are actually just mislabeled.

    Background:
    In PRTG 26.3.122.1665,… 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

20. Monitoring of Individual Azure File Shares (per‑share capacity, usage, and performance)

    Currently, the Azure Storage Account sensor in PRTG only provides metrics at the storage-account level.
    As an IT admin, I need the ability to monitor each Azure File Share separately, including metrics such as used space,
    free space, total capacity, file count, and I/O performance.

    Please introduce a new Azure File Share sensor that queries per-share metrics.

    Possible channels:
    Total capacity
    Used space
    Free space
    File count
    IOPS / throughput
    Ingress / egress

    7 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

    Gathering Feedback  ·  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