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

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

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

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

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

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

10. More Essential Sensors for the Multi-Platform Probe on Linux

    As a Systems Engineer running PRTG multi-platform probes on Linux in environments without Windows probe systems, I want more essential sensors, for example, native NTP/SNTP and LDAP(S) sensors to be available on the multi-platform probe,
    so that I can monitor time synchronization and directory service availability — two services critical for authentication and infrastructure health — directly from my Linux probes, without maintaining a Windows remote probe or building custom script workarounds.

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Delete…  ·  Admin →
    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
    In Progress  ·  AdminIsidora Jeremic (Admin, Paessler) responded

    Hi there,

    Exciting news! Your idea is now in progress! Our team has started working on bringing this feature/improvement to life.

    We're diligently developing and testing, and we'll keep you updated on our progress. We're excited about the positive impact this will have for Paessler users.

    Thanks for your patience and for helping us enhance our products.

    Best regards,

    The Paessler Product Team

11. Proxmox Credential Placeholders for Custom Script Sensors

    As a Systems Engineer monitoring Proxmox hypervisors with both native PRTG sensors and custom EXE/Script Advanced (PowerShell) sensors, I want the device-level "Credentials for Proxmox" fields (API Token ID, Secret, Port) to be available as placeholders (e.g., %proxmoxtokenid, %proxmoxtokensecret, %proxmoxport) in my script parameters, so that I maintain the API token in one single place and token rotation no longer requires redundant, error-prone updates across two credential sections.

    Background:
    We heavily rely on Custom EXE/Script Advanced Sensors (PowerShell) to monitor our hypervisors for specific metrics, like aging snapshots. While migrating to Proxmox, we noticed that we cannot pass the newly introduced "Credentials for Proxmox" (API Token ID, Secret, and Port) to our custom scripts, as there are no placeholders available.
    Support confirmed this limitation and suggested using the generic "Credentials for Script Sensors" instead. However, if we want to use PRTG's native Proxmox sensors alongside our custom scripts, this workaround forces us to maintain the exact same API token in two different sections. This duplicate credential management is a nightmare for token rotation and completely violates the DRY principle.
    Since the native Proxmox integration is a relatively recent addition to PRTG, it seems mapping these credential fields to the custom script engine was simply forgotten during development.
    Please close this gap and add standard placeholders (e.g., %proxmoxtokenid, %proxmoxtokensecret, %proxmoxport). This small fix would allow us to securely pass the credentials to our scripts without forcing redundant data entry.

    As a Systems Engineer monitoring Proxmox hypervisors with both native PRTG sensors and custom EXE/Script Advanced (PowerShell) sensors, I want the device-level "Credentials for Proxmox" fields (API Token ID, Secret, Port) to be available as placeholders (e.g., %proxmoxtokenid, %proxmoxtokensecret, %proxmoxport) in my script parameters, so that I maintain the API token in one single place and token rotation no longer requires redundant, error-prone updates across two credential sections.

    Background:
    We heavily rely on Custom EXE/Script Advanced Sensors (PowerShell) to monitor our hypervisors for specific metrics, like aging snapshots. While migrating to Proxmox, we noticed that we cannot pass the newly… 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

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

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

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

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

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

17. Proxy Support for SSL Certificate Sensor

    As an IT Infrastructure Manager operating PRTG in a network without direct internet access,
    I want the SSL Certificate sensor to natively support the HTTP proxy settings configured on the parent device,
    so that I can monitor the SSL/TLS certificates of external websites through our proxy — just like I already can with HTTP-based sensors — without needing to rely on a separate monitoring tool.

    Background: We are using PRTG without direct internet access. With the proxy setting of the device we can monitor a HTTPS website, but not the SSL certificate of that site. That is a problem for us (we are currently still using our old monitoring tool for just that purpose because PRTG can't do it).

    As an IT Infrastructure Manager operating PRTG in a network without direct internet access,
    I want the SSL Certificate sensor to natively support the HTTP proxy settings configured on the parent device,
    so that I can monitor the SSL/TLS certificates of external websites through our proxy — just like I already can with HTTP-based sensors — without needing to rely on a separate monitoring tool.

    Background: We are using PRTG without direct internet access. With the proxy setting of the device we can monitor a HTTPS website, but not the SSL certificate of that site. That is a problem for… 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

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

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

20. Synology NAS Sensor Support on the Multi-Platform Probe

    As a Systems Engineer, I want to be able to use Synology NAS sensors on the multi-platform probe, so that I can monitor my Synology storage devices from Linux-based or containerized probe environments without depending on a Windows remote probe

    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

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

    Hi there,

    Great news! Your idea has been reviewed and is now officially on our roadmap! This means we've committed to developing it in the future.

    While we don't have an exact release date yet, we're planning to implement this feature/improvement as part of our upcoming development cycles. We're excited about the value this will bring to our users.

    We appreciate your patience as we work to bring this to fruition. We'll let you know once it moves into active development.

    Thanks for helping us build a better Paessler!

    Best regards,

    The Paessler Product Team