77 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

   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

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

   25 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

3. Redfish Temperature Sensor

   As a PRTG user, I want to monitor individual temperature readings from any Redfish-compliant server (HPE, Dell, Lenovo, Supermicro, etc.) — one sensor instance per temperature probe — so that I get granular thermal visibility and per-sensor alerting.

   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

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

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

   14 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

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

   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

   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

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

   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

   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

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

   8 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

8. Enable PowerShell 7 Support for PRTG Custom Sensors

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

   24 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

   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
   In Progress  ·  AdminJörg Hollerith (Product Manager, 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

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

   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

   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

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

    14 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

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

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

    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

    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

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

    26 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

    7 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

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

    •  

    •  

    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

    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

15. Redfish Fan State sensor

    As a PRTG user, I want a single sensor per server (HPE, Dell, Lenovo, Supermicro, etc.) that monitors all fans via Redfish, so that I get a consolidated view of fan health and speeds without cluttering my device tree with one sensor per fan.

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Edit…  ·  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  ·  AdminJörg Hollerith (Product Manager, 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

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

17. SNMP Custom Table Sensor: Auto-naming from String Columns & Multi-Column Monitoring

    Problem:
    The SNMP Custom Table Sensor has critical limitations:
    Sensors are named by row identifiers (e.g., "Table: OID / 128.141.183.198.171.212") instead of human-readable names from string columns
    Only one column per sensor - monitoring multiple metrics per table row requires multiple separate sensors
    String columns cannot be used for naming or identification
    This makes monitoring dynamic SNMP tables (APs, interfaces, VPN users) impractical at scale.

    Requested Features:
    1. Automatic Naming from String Columns
    Add option to specify which table column contains sensor names
    Example: Use column .1.3 (AP Name) instead of MAC address
    Result: Sensors named "AP-Office-Floor1" instead of "Table: OID / 128.141.183.198.171.212"
    2. Multi-Column Monitoring per Row
    Allow multiple columns as channels within one sensor per table row
    Example: One sensor "AP-Office-Floor1" with channels: Status, Client Count, Uptime
    Configuration Example:
    Table OID: 1.3.6.1.4.1.14823.2.2.1.5.2.1.4
    Naming Column: .1.3
    Columns to Monitor: .1.2 (Clients), .1.19 (Status), .1.8 (Uptime)

    Result:
    Sensor: "AP-Office-Floor1"
    ├─ Channel: Status
    ├─ Channel: Clients
    └─ Channel: Uptime
    Use Cases:
    Wireless APs: Monitor status, clients, traffic per AP with readable names
    Network Interfaces: Monitor bandwidth, errors per interface with interface names
    VPN Sessions: Monitor per-user metrics with usernames
    Virtual Machines: Monitor CPU, RAM per VM with VM names

    Business Value:
    - Immediate identification in dashboards/maps/alerts
    - No manual renaming of hundreds of auto-discovered sensors
    - Better organization - related metrics grouped per entity

    Current Workarounds (all inadequate):
    SNMP Library: Creates channels (not sensors), still uses row IDs for naming
    Manual renaming: Impractical for 50+ dynamic entries
    Custom scripts: Requires PowerShell/Python + PRTG API knowledge
    Implementation Suggestion:
    Add optional fields to SNMP Custom Table Sensor configuration:
    "Naming Column OID" (optional)
    "Select multiple columns" checkbox
    Backward compatible - existing sensors unchanged
    This is a common monitoring scenario that currently has no native PRTG solution.

    Problem:
    The SNMP Custom Table Sensor has critical limitations:
    Sensors are named by row identifiers (e.g., "Table: OID / 128.141.183.198.171.212") instead of human-readable names from string columns
    Only one column per sensor - monitoring multiple metrics per table row requires multiple separate sensors
    String columns cannot be used for naming or identification
    This makes monitoring dynamic SNMP tables (APs, interfaces, VPN users) impractical at scale.

    Requested Features:
    1. Automatic Naming from String Columns
    Add option to specify which table column contains sensor names
    Example: Use column .1.3 (AP Name) instead of MAC address
    Result: Sensors named "AP-Office-Floor1" instead of "Table:… more

    6 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

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

19. WMI Service Group Sensor

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

    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

    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

20. Native vCenter Alarm Monitoring Sensor

    As a Systems Engineer managing a VMware vSphere environment, I want a native PRTG sensor that monitors vCenter alarms directly, so that I can gain complete visibility into the health status of my virtualized infrastructure without relying on third-party scripts or workarounds, ensuring I'm immediately aware of critical issues flagged by vCenter's own alarm system.

    There is a third party sensor (https://github.com/Jannos-443/PRTG-VMware-Alerts), but something this fundamental should be built in.

    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