53 results found

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

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

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

4. Dynamic sensor assignment to Business Process channels via tags

   As a Systems Engineer managing a large or frequently changing PRTG environment, I want to define a sensor tag as a dynamic filter for a Business Process channel, so that sensors are automatically added to or removed from the channel when their tags change — eliminating manual reconfiguration of Business Process Sensors every time the environment changes.

   Background:
   Business Process Sensor configurations are currently largely static. Sensors have to be manually assigned to individual Business Process channels.
   For larger PRTG environments, it would be very useful to have the option to dynamically populate Business Process channels based on sensor tags.
   Feature Request: A Business Process channel should optionally be configurable using a PRTG sensor tag as a dynamic filter.

   For example:
   Channel 1 → Tag: BPSServiceA
   Channel 2 → Tag: BPSServiceB
   Channel 3 → Tag: BPSServiceC

   The Business Process Sensor would then automatically include all sensors that have the corresponding tag.

   For example:
   Channel 1
   Tag: BPSServiceA
   → Server 01 – HTTP Sensor
   → Server 02 – HTTP Sensor
   → Server 03 – HTTP Sensor
   → Server 04 – HTTP Sensor

   If a new sensor is assigned the tag BPSServiceA, it would automatically become part of Channel 1.
   If the tag is removed from a sensor, the sensor would automatically be removed from the channel.

   This would make Business Process Sensors significantly more dynamic and scalable. Changes in the monitored environment would no longer require manual updates to the Business Process configuration.
   For example, when a new server is added, an administrator would only need to assign the appropriate tag to its sensors. The Business Process Sensor would automatically include them.
   This would be especially valuable in larger environments and for automated monitoring deployments, where sensors are frequently added, removed, or changed.
   Overall, this feature would greatly reduce administrative effort and make Business Process Sensors much easier to maintain at scale.

   As a Systems Engineer managing a large or frequently changing PRTG environment, I want to define a sensor tag as a dynamic filter for a Business Process channel, so that sensors are automatically added to or removed from the channel when their tags change — eliminating manual reconfiguration of Business Process Sensors every time the environment changes.

   Background:
   Business Process Sensor configurations are currently largely static. Sensors have to be manually assigned to individual Business Process channels.
   For larger PRTG environments, it would be very useful to have the option to dynamically populate Business Process channels based on sensor tags.… 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

5. Bulk-add sensors to Business Process channels (multi-select & ID list)

   As a Systems Engineer setting up Business Process Sensors with many underlying sensors, I want to add multiple sensors to a BP channel in one operation — via multi-select in the device tree or by pasting a list of sensor IDs — so that I can configure large Business Processes in minutes instead of adding each of e.g. 50 sensors individually.

   Background:
   When configuring a Business Process Sensor, sensors currently have to be added one by one, either by entering the sensor ID or by selecting each sensor individually from the Device Tree.
   This becomes extremely time-consuming when a Business Process consists of a large number of sensors. For example, if 50 sensors need to be assigned to a channel, each sensor currently has to be selected and added individually.
   Feature Request: The Device Tree should support multi-selection of sensors when adding objects to a Business Process channel.

   For example:
   Select a device or probe in the Device Tree
   Select multiple sensors
   Click "Add to Business Process Channel"
   All selected sensors are added at once

   Additionally, it would be very useful to support bulk assignment using a list of sensor IDs.
   For example:
   1234
   1235
   1236
   1240
   1241
   All sensors in the list could then be added to a selected BP channel in a single operation.
   Bulk selection would significantly reduce the time required to configure Business Process Sensors. This would be particularly useful for large Business Process configurations and environments where many sensors need to be assigned to multiple Business Processes. It would also make the initial configuration of complex Business Processes much more efficient.

   As a Systems Engineer setting up Business Process Sensors with many underlying sensors, I want to add multiple sensors to a BP channel in one operation — via multi-select in the device tree or by pasting a list of sensor IDs — so that I can configure large Business Processes in minutes instead of adding each of e.g. 50 sensors individually.

   Background:
   When configuring a Business Process Sensor, sensors currently have to be added one by one, either by entering the sensor ID or by selecting each sensor individually from the Device Tree.
   This becomes extremely time-consuming when a Business… 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

6. Show full object context (probe → device → sensor) in Business Process channel sensor lists

   As a Systems Engineer validating or troubleshooting a Business Process Sensor configuration, I want the list of assigned sensors per channel to display the full object path (probe, device, sensor name, sensor ID, and optionally sensor status) with sorting and filtering, so that I can immediately identify which sensor belongs to which device without looking up each sensor ID individually.

   Background:
   When configuring a Business Process (BP) Sensor, the objects assigned to a channel are currently displayed mainly by sensor name and sensor ID. For larger Business Process Sensors, this makes it difficult to see which device and probe a sensor actually belongs to.
   This becomes especially problematic when multiple sensors with the same name are used within the same channel. For example, there may be several sensors named "Ping" or "CPU Load" from different devices.

   Currently, the only way to determine which device a specific sensor belongs to is to search for each sensor ID individually in PRTG.
   This can become very time-consuming when a Business Process contains a large number of sensors and you want to verify that all required sensors have been assigned correctly.

   Feature Request: The list of sensors assigned to a BP channel should display additional information, such as:
   Probe
   Device
   Sensor
   Sensor ID
   Optionally, sensor status

   For example:
   Current:
   CPU Load – ID 1234
   Desired:
   Probe A → Server 01 → CPU Load – ID 1234
   Ideally, the list should also support sorting and filtering.
   This would make the configuration of Business Process Sensors much more transparent and easier to maintain.
   Administrators could immediately identify which sensors are assigned to a channel without having to search for each sensor ID individually.
   It would also make troubleshooting and validating complex Business Process configurations significantly easier.

   As a Systems Engineer validating or troubleshooting a Business Process Sensor configuration, I want the list of assigned sensors per channel to display the full object path (probe, device, sensor name, sensor ID, and optionally sensor status) with sorting and filtering, so that I can immediately identify which sensor belongs to which device without looking up each sensor ID individually.

   Background:
   When configuring a Business Process (BP) Sensor, the objects assigned to a channel are currently displayed mainly by sensor name and sensor ID. For larger Business Process Sensors, this makes it difficult to see which device and probe a… 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

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

8. DNSSEC Sensor

   As an operator of security‑critical DNS infrastructure, I want a native PRTG sensor that monitors DNSSEC signature status and trust chain integrity for my DNS zones, so that I can detect issues such as missing DS records, expiring signatures, or failed validation before they impact production.

   Therefore, a sensor must check the following DNSSEC components:

   AD flag (validation status)
   Presence of RRSIG records and their signature expiration time (warn if remaining time is low!)
   Count of DNSKEY records including KSK (257) and ZSK (256)
   Count of DS records in the parent zone (=0 is error)
   Trust chain consistency (DS -> DNSKEY -> RRSIG)

   As an operator of security‑critical DNS infrastructure, I want a native PRTG sensor that monitors DNSSEC signature status and trust chain integrity for my DNS zones, so that I can detect issues such as missing DS records, expiring signatures, or failed validation before they impact production.

   Therefore, a sensor must check the following DNSSEC components:

   AD flag (validation status)
   Presence of RRSIG records and their signature expiration time (warn if remaining time is low!)
   Count of DNSKEY records including KSK (257) and ZSK (256)
   Count of DS records in the parent zone (=0 is error)
   Trust chain consistency (DS ->… 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

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

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

11. Add "Output Source" Channel to SNMP UPS Status Sensor for Utility Power Loss Detection

    As a Systems Engineer responsible for monitoring UPS infrastructure,
    I want the SNMP UPS Status sensor to include an "Output Source" channel that indicates whether the UPS is supplying power from utility (mains) or battery,
    so that I am immediately alerted when a UPS switches to battery power due to a utility outage, without having to wait for the battery charge to drop to a warning or error threshold.

    Background:
    I've just started testing the SNMP UPS Status (NEW) sensor with Eaton UPSs. Having the Battery Status, Charge Remaining, Current Load, and Estimated Time Remaining are all super handy.
    However, there's one critical thing missing. While the Charge Remaining channel does have warning/error limits configured for alerting (by default, 50% remaining and 20% remaining, respectively), the Battery Status always shows "Battery Normal". It may be that the battery status is indeed normal and functioning, but when the UPS has lost utility power and is running on battery, there's no way to know that the UPS is now on battery without looking at the charge level or waiting for it to hit a charge limit for alerting, because the Battery Status remains "Battery Normal", even when utility power is lost. It would be handy to have a way to determine on the next sensor scan if a UPS has switched to battery power, indicating utility power has failed.
    I'd propose a new channel for this sensor, in addition to Battery Status, called "Output Source". If I check the Eaton MIB, the OID 1.3.6.1.2.1.33.1.4.1.0 shows a value of either "normal" (when the UPS is on utility power), or "battery" (when the UPS has switched to supplying power via the battery). This would be a perfect addition to this built in SNMP UPS Status Sensor, where "normal" would be an OK status, and "battery" would be a Warning status in PRTG.
    Alerting on the Output Source channel could also be disabled by the user if they have a UPS that operates in such a way that the output source is always the battery, and is constantly being topped up by AC power.

    As a Systems Engineer responsible for monitoring UPS infrastructure,
    I want the SNMP UPS Status sensor to include an "Output Source" channel that indicates whether the UPS is supplying power from utility (mains) or battery,
    so that I am immediately alerted when a UPS switches to battery power due to a utility outage, without having to wait for the battery charge to drop to a warning or error threshold.

    Background:
    I've just started testing the SNMP UPS Status (NEW) sensor with Eaton UPSs. Having the Battery Status, Charge Remaining, Current Load, and Estimated Time Remaining are all super handy.
    However,… more

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    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

12. SNMP Cisco System Health Sensor: Add "Used Memory " Channel

    As a Network Engineer, I want to see a 'Used Memory (%)' channel alongside the existing 'Available Memory' channel in the SNMP Cisco System Health sensor, so that I can choose the metric that best fits my alerting thresholds and dashboards.

    •  

    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

    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

13. HPE ProLiant Sensor Support on the Multi-Platform Probe

    As a Systems Engineer, I want to be able to use HPE ProLiant sensors on the multi-platform probe, so that I can monitor my HPE server hardware from Linux-based or containerized probe environments without depending on a Windows remote probe.

    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

14. Enhanced Cisco Catalyst 9800 WLC Monitoring Sensors

    As a Network Engineer, I want comprehensive, out-of-the-box sensors for the Cisco Catalyst 9800 Wireless LAN Controller — covering SSID status, per-SSID client counts, per-SSID traffic, WLC high-availability status, and disk space — so that I can proactively manage my wireless infrastructure without relying on manual CLI checks or custom workarounds.

    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

    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

15. HPE VM Essentials (VME) Cluster Monitoring Sensor

    As an IT Infrastructure Manager,
    I want native PRTG sensors for HPE VM Essentials (VME) clusters that monitor cluster health, host performance, VM status, and resource utilization,
    so that I can maintain unified visibility across my virtualization environment after migrating away from VMware, without relying on manual custom sensor configurations.

    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

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

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

    21 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  ·  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

18. Native Linux PSI (Pressure Stall Information) Sensor for Improved Resource Pressure Monitoring

    As a Systems Engineer managing Linux server infrastructure with PRTG, I want a native Linux PSI sensor that reads CPU, memory, and I/O pressure stall metrics directly from /proc/pressure/, so that I can accurately detect resource contention, identify performance bottlenecks earlier, and replace fragile custom SSH script workarounds with a standardized, maintainable monitoring solution.

    Many organizations using PRTG rely on the built-in SNMP Linux Load Average sensor to monitor system load on Linux servers. While this works for basic monitoring, the traditional load average metric has well-known limitations: it only reflects the number of runnable or waiting tasks and does not clearly indicate which resource (CPU, memory, or I/O) is causing contention.

    Modern Linux kernels provide a more advanced metric called Pressure Stall Information (PSI) that directly measures resource pressure. PSI exposes how long tasks are stalled waiting for CPU, memory, or I/O resources, providing a much clearer indicator of real performance bottlenecks and system saturation.

    PSI metrics are available in modern kernels via:
    /proc/pressure/cpu
    /proc/pressure/memory
    /proc/pressure/io

    Why PSI support would benefit PRTG users:

    • More accurate detection of CPU, memory, and I/O contention

    • Earlier identification of performance bottlenecks

    • Better alerting and capacity planning

    • Alignment with modern Linux observability practices

    • Reduced need for custom SSH script sensors

    • Currently, PSI monitoring can only be implemented via custom scripts, which reduces maintainability and standardization in larger environments.

    Suggested implementation:

    • Introduce a dedicated “Linux PSI Sensor”

    • Or extend existing Linux sensors to include PSI channels (CPU, memory, I/O pressure)

    Native PSI support would greatly improve Linux performance monitoring in PRTG.

    As a Systems Engineer managing Linux server infrastructure with PRTG, I want a native Linux PSI sensor that reads CPU, memory, and I/O pressure stall metrics directly from /proc/pressure/, so that I can accurately detect resource contention, identify performance bottlenecks earlier, and replace fragile custom SSH script workarounds with a standardized, maintainable monitoring solution.

    Many organizations using PRTG rely on the built-in SNMP Linux Load Average sensor to monitor system load on Linux servers. While this works for basic monitoring, the traditional load average metric has well-known limitations: it only reflects the number of runnable or waiting tasks and does… 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

19. Native Podman Container Monitoring Sensor

    As a Systems Engineer managing containerized workloads across different operating systems and environments, I want a dedicated Podman container monitoring sensor in PRTG so that I can monitor the health, status, resource usage, and uptime of my Podman containers, with the same depth and ease that the existing Docker sensor provides for Docker environments.

    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

20. OCSP Support for SSL Certificate Monitoring Without CRL Dependency

    As a Systems Engineer responsible for monitoring SSL/TLS certificates,
    I want PRTG's SSL Certificate sensor (and related sensors) to support OCSP (Online Certificate Status Protocol) as a standalone certificate revocation verification method,
    so that I can accurately monitor certificate validity and revocation status even when the Certificate Authority no longer provides a CRL (Certificate Revocation List), avoiding false alerts or "Unable to Check Revocation Status" warnings that undermine the reliability of my monitoring setup.

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