PRTG Release Notes:
Stable Channel

With this PRTG version, we introduce the new FTP v2 sensor as the successor to the existing FTP sensor. The sensor monitors file servers via the File Transfer Protocol (FTP) and FTP over SSL (FTPS), measuring the server's response time and returning the server's response message. You configure it via an FTP URL, and can set the FTP port, request timeout, and encryption mode (Implicit, Explicit, or None), so you can verify that an FTP/FTPS service is reachable, responsive, and enforcing transport-level security.

We extended the System Health v2 sensor to run on the upcoming Multi-Platform Probe on Windows, in addition to its existing support on Linux multi-platform probe and the classic remote probe. This lets you monitor CPU load, available memory, and overall system health on Windows systems running the multi-platform probe. All channels, settings, and limits are unchanged from the existing sensor.  It also adds a new channel called Health, which is a composite of CPU and memory load.

With this PRTG version we introduce the new VMware Virtual Machine (REST & VI/JSON) sensor, which is the successor to the VMware Virtual Machine (SOAP) sensor. This sensor lets you monitor a VMware virtual machine on vSphere using the REST and VI/JSON APIs, covering CPU, memory, disk, network, snapshot, and power-state metrics. You can configure whether the sensor goes into a Down status when the VM is powered off, or instead reflects status purely through its channel lookups. The sensor supports both the classic remote probe and the multi-platform probe, and requires vCenter 8.0.1 or newer for its performance metrics.

With this PRTG version, we introduce the new VMware Host Performance (REST & VI/JSON) sensor as a successor to the VMware Host Performance (SOAP) sensor. The sensor monitors CPU, memory, disk, and network performance metrics of a VMware host via the vSphere REST and VI/JSON API, enabling you to proactively detect performance degradation on your hosts. Please note that the sensor requires vSphere version 8.0.1.0 or above.

With this PRTG version we introduce the new WMI Microsoft IIS Application v2 sensor, which monitors a Microsoft Internet Information Services (IIS) server via WMI, including applications that run on IIS such as Microsoft SharePoint or Microsoft Reporting Services (SSRS). The sensor reports throughput (total, received, and sent bytes), GET and POST request counts, and Not Found error counts, so you can track web service load and availability. The sensor supports the classic remote probe and will run on the upcoming Multi-Platform Probe for Windows.

• Important: Please note that a user without administrative rights has to be added to Remote Management Users and Performance Monitor Users groups. Additionally, the user needs Remote Enable permission set in the WMI root namespace.

You can now monitor the disk usage of a logical disk or mount point on a Windows system using the new WMI Logical Disk I/O v2 sensor, the successor to the WMI Logical Disk I/O sensor. The sensor reads performance counters for a logical partition (identified by its drive letter, such as C) and returns read/write throughput, I/O operations, queue lengths, timing, and free space so that you can detect disk I/O bottlenecks and capacity issues before they affect application performance. This sensor works on PRTG Classic Probe and will be supported on the upcoming Multi-Platform Probe for Windows.

You can now monitor the input/output parameters of a physical hard disk on a Windows system using the new WMI Physical Disk I/O v2 sensor, the successor to the Windows Physical Disk I/O sensor. The sensor provides read/write throughput, I/O operations, queue lengths, and timing percentages to help detect disk I/O bottlenecks that can affect application performance and stability. This sensor works on PRTG Classic Probe and will be supported on the upcoming Multi-Platform Probe for Windows.

With this PRTG version, we introduce a new Default UI setting under System Settings > System Administration > User Interface, so you can make the New UI the default target for system-generated links such as email notifications and reports. Select New UI in the Default UI option to switch these links over; the classic UI remains the fallback until you do.

 We performed sanitization on EXE/Script sensor parameters to prevent information disclosure.

We further hardened PRTG against information disclosure. We will provide more details at a later date.

We enabled SSL certificate verification for AWS sensors when they connect through a proxy. In addition, unreachable regions no longer time out the meta-scan or cause it to fail.

Beta sensors are now always visible in the Add Sensor dialog. If experimental features are turned off, these sensors appear greyed out together with a hint that you need to enable experimental features under Setup > Monitoring to use them, so you can discover what is available without having to enable the flag first.

We added the regions Europe (Spain) and Europe (Zurich) to the Region selection of the Cloud HTTP v2 and Cloud Ping v2 sensors.

We improved the NetApp System Health v2 sensor by adding two additional channels without default limits: 'Spare Disks Total' and 'Spare Size Total'. For newly created sensors, “Spare Disks Available” no longer has default limits either, since a single fixed threshold doesn’t fit every environment equally well. For sensors that already exist, this channel keeps its previous default limits to avoid changing existing alerting behavior.

We removed the fixed 60-second minimum interval from a large number of sensor types, including many SNMP sensors such as SNMP Memory v2, so you can scan more frequently where your setup allows it. We also adjusted the recommended interval on several other sensors, in most cases to a longer interval, to better match typical usage and reduce unnecessary load. The scanning interval of your existing sensors is not changed; these adjustments only apply to new sensors or when you manually change an interval yourself.

We improved the automatic update so that a failed update no longer runs in a loop. If the installed version does not match the version the auto-update was targeting, PRTG creates a To Do ticket to let you know that the update failed, as before, and now also removes the leftover installer file at core service start so the failed installer is not picked up again on the next run.

We improved the performance of auto-discoveries in PRTG for installations with a large number of stored auto-discovery history entries.

With this PRTG version we introduced a new setting in the Monitoring section of System Administration: AI Features. With this new setting you can allow AI features such as Alarm Insights on your PRTG installation. If you select Disable, PRTG does not send your monitoring data for AI processing. The availability of AI features depends on your PRTG license. This setting is only available for PRTG administrative users.

With this PRTG version, we added support for the new UI and PRTG API v2 for Paessler PRTG Hosted Monitor, bringing it in line with the functionality already available to on-premises PRTG installations. This includes support for PRTG Hosted Monitor’s login mechanism in the new UI and PRTG API v2, with the goal of functional parity with the classic PRTG web interface, so you can start migrating to the new UI. The new UI and PRTG API v2 will be available as an opt-in feature, which you can activate for a specific PRTG Hosted Monitor instance. This becomes possible as soon as this PRTG stable version has been rolled out to all PRTG Hosted Monitor instances, currently planned for end of November.

Subscription only

The new feature Alarm Insights, that we introduced with PRTG version 26.3.124.1727 as an early preview access, is now available for Subscription and Paessler PRTG Enterprise licenses when you are logged in with an administrative user account. PRTG will install the relevant AI agent service when you update to this PRTG version.

With this PRTG version, new features in the new UI are now highlighted with a blue badge in the side menu, helping you discover recently added capabilities like Alarm Insights and Auto-Discovery tasks as soon as you open PRTG.

You are now able to create a device template in the new UI from an already existing device for use with Auto-Discovery tasks. You will not be redirected to the classic PRTG interface during device template creation in the new UI via context menu.

You can now access the historic sensor data directly in the New UI through the new Historic Data tab on a sensor, so you can run ad-hoc reports over a selected time frame and export monitoring data for analysis in external tools without switching to the classic web interface.

With this PRTG version we introduce Geo Maps in the new UI, letting you see the physical location of your probes, groups, and devices directly on a map. A geo location card now appears in the Info tab of probes, groups, and devices, showing the relevant devices for that object with icons color-coded by status; if multiple devices share the same location, a badge on the icon shows how many. The location card will not be displayed if you disable the Geo Map.

You can now edit devices, sensors, and channels via bulk edit in the new UI. Select the objects you want to change and use the new Edit settings action to apply configuration changes to the whole set in one operation, matching what is already possible in the PRTG Classic web interface.

You are now able to use our new AI Chatbot Max again on the Welcome Page in new UI. Clicking the Start Chatting button opens a slide-in panel on the right side of the page, where you can interact with the chatbot. MAX AI has in-depth knowledge of PRTG and is ready to assist you with questions and troubleshooting directly from the Welcome Page.

We renamed the tab Insights to Top 10 so that the name better matches the content displayed on the tab.

Various other minor fixes and improvements, updated user manual.

 We updated the French, Portuguese, Dutch, Russian, Chinese and Japanese languages files for certain sensor types.

We updated the German and Spanish language files.

With this PRTG version, we automatically enable the Appserver on update so that the Open New UI button and the REST API v2 are directly available without needing to activate the Appserver manually first. Before activating, PRTG checks whether enough memory is free and skips automatic activation if not, so it does not enable the Appserver on installations already running close to their resource limit. You can still activate it manually later from System Administration.

To ensure secure connection furthermore, the connection between the PRTG core server and the Application Server now uses TLS 1.3 and TLS 1.2 by default. The corresponding option has been removed from Setup | System Administration | User Interface as TLS version 1.1 is outdated.

In preparation for changing the Probe-to-core communication from NATS to QUIC, PRTG will create a TO DO ticket that informs you about the change in case you have an integrated or remote NATS Server active. QUIC is a UDP based, reliable and modern transport protocol that enables you to onboard (remote) probes easier with a more secure connection. A direct TCP Connection remains available as fallback, in case your network does not allow QUIC communication. We therefore also simplified onboarding a Multi-Platform Probe (MPP) with QUIC/TCP by showing the public server certificate directly in the PRTG Web UI. A new read-only text box displays the base64 PEM-encoded CA certificate loaded by the probe-adapter for the QUIC/TCP listeners, including the root CA if one is present, so you can easily copy it over to your MPP instead of having to locate and export it manually. The Multi-Platform Probe will support QUIC with upcoming releases. For more information, please see this knowledge base article: How can I transfer my multi-platform probes from NATS to QUIC?

New PRTG installations no longer install the integrated NATS component. The multi-platform probe now connects to PRTG using QUIC or TCP directly, which reduces the complexity of the PRTG setup. Please note that existing NATS installations continue to work and are updated to the current NATS version so that your existing multi-platform probe connections are not affected.

PRTG now ships and installs the PRTG AI Agent service together with the Application Server. The service runs as a Windows service and writes its log to %ProgramData%\Paessler\PRTG Network Monitor\Logs\aiagent\aiagent.log. The agent is the foundation for Alarm insights and future AI-based features.

With this PRTG version, PRTG will install the UVexplorer automatically, ensuring secure communication. PRTG will install files and components of the UVexplorer when you update to this PRTG version and the UVexplorer integration will not be overwritten when you install future PRTG updates. Please note that the installation of UVexplorer depends on your PRTG license. For more information about the UVexplorer setup and release notes, please see our Knowledge Base articles PRTG UVexplorer Release Notes | Paessler Knowledge Base and https://helpdesk.paessler.com/en/support/solutions/articles/76000089448.

With this PRTG version we removed and therefore replaced several API v2 endpoints. We already announced the deprecation of these endpoints with PRTG version 26.3.122.1665. You can find an updated list for all affected endpoints here: PRTG API v2 Overview.

We fixed an issue where the warning and error limits on a channel were evaluated against a scaled value instead of the limit you configured. The configured limit was shown correctly in the channel settings, but the sensor message revealed that a divide, multiply, or scale factor was also applied internally to the limit, so a limit of 30 on a channel with division factor 10 was effectively triggered at 3. This issue affected the SNMP Custom and SNMP Custom v2 sensor.

We fixed an issue where the configuration details for Single Sign-on were not transmitted via support bundle when you selected the Contact Support option.

We fixed an issue where, with two or more remote probes set up in PRTG, the device tree incorrectly nested all probe devices and their child objects (such as the auto-discovery inbox and discovered devices) under a single probe instead of showing each remote probe with its own devices and objects nested directly beneath it. This occurred on both Paessler PRTG Hosted Monitor and Paessler PRTG Network Monitor.

We fixed an issue where PRTG ignored values above 30 days configured for PRTG Web Server Log Records under Historic Data Purging. Older web server log files are now retained for the full number of days you set, instead of always being deleted after 30 days.

We fixed an issue where the Included Sensors section of the Add Report dialog listed groups and devices as selectable sensors. This issue only occurred when you were logged in with a PRTG admin user account.

We fixed an issue for PRTG access via link, for example in notifications, where you had to log in again even with an open and active PRTG session.

We fixed an issue that occurred since PRTG version 26.3.124, where pausing a probe or group whose devices and sensors were not paused themselves caused ongoing, unnecessary CPU load on the PRTG core. The issue occurred because active objects nested below a paused parent incorrectly had their internal state repeatedly marked as changed on every scheduler cycle. The issue could happend on PRTG Network Monitor and PRTG Hosted Monitor.

 We fixed an issue where logging in to PRTG via Single Sign-on resulted in a 404 error when you used a non-default (custom) HTTPS port for the Web UI. The issue started to occur with version 26.3.122.1665 and affected setups where the PRTG web interface used a non-standard port.

We fixed an issue in PRTG Hosted Monitor where Entra ID single sign-on silently failed if the configured client secret had expired. With moving to the new authentication flow, you were simply redirected to the login page without a proper error message in such cases. PRTG now detects this error from Auth0 and informs you so you can check and replace the client secret.

We fixed an issue on PRTG Hosted Monitor (PPHM) where the notification sent when a user is deleted used the deleted user's own email address instead of the email of the administrator who performed the deletion.

We fixed an issue that occurred when you updated to PRTG version 26.2.120.1477 in certain cases where you would receive Internal Server Error messages right after logging in to your instance.

We fixed an issue on the Multi-Platform Probe where buffered monitoring data was not sent to the PRTG core server after a longer outage of the connection. Graphs and data tables showed a gap for the outage period even though the probe had buffered data locally. Buffered data is now delivered after the connection is restored.

We significantly reduced the time auto-discovery takes on the multi-platform probe, from around 5 minutes down to a few seconds. Previously, the core waited for a response that the multi-platform probe never answers, and that unanswered request stalled discovery until it timed out.

We fixed an issue where MQTT sensors (such as MQTT Statistics and MQTT Subscribe Custom) could, in rare cases, stop responding and never deliver results. The issue was caused by a deadlock during sensor creation and is now resolved.SIMATIC S7-1200/1500 Hardware Status: We fixed the Hardware Fault Count primary channel of the SIMATIC S7-1200/1500 Hardware Status sensor so that a parent module no longer double-counts a child's fault. A faulty module contributes 1 to the count only when none of its charted descendants is already counted, ensuring each faulty piece of hardware is counted exactly once.

We fixed an issue where the SSL/TLS Certificate sensor closed its TLS connections without sending a proper TLS close_notify alert. This caused the connection to end abruptly from the monitored server’s perspective, which could result in error log entries such as “stream truncated” on the server side.

We fixed an issue in the New UI where copying and pasting a device or sensor into a user's own personal group failed with a permission error, even though the user has write access to that group. This happened when the user's access to a parent group elsewhere in the tree was set to read-only.

We fixed an issue where it was not possible to edit the License Key or License Name on the /settings/status/license/activation page in the New UI. The License Key or License Name was not changed previously when you clicked on Update License. Additionally, we fixed an issue for the Activation Type that did not display the settings when you selected Manual (offline activation).

We fixed an issue where a sensor could show fewer channels than expected in the New UI, with its primary channel missing, if the primary channel had been set (for example via the API) to a channel that did not exist yet because the sensor had not completed its first scan. Affected sensors also got stuck with Last Scan showing N/A, and Scan Now did not trigger a new scan.

• We fixed an issue in the new UI where a user logging in for the very first time was redirected to the Welcome page after sign-in, even when they had opened a deep link to a specific page such as Maps, Auto-Discovery, or Reports.
• We now redirect correctly from the classic PRTG web interface https:yourserver/home to the homepage of the New UI https:yourserver/.

• We improved the performance in the New UI when you delete multiple objects via bulk edit change.
• We improved the performance in the New UI especially for larger installations where the Object tree loads faster by fetching only the rows it displays and loads the remaining pages in parallel.

We fixed an issue where it was not possible to create and start a Report with the default Start and End date settings. Previously, the Run Report button would not trigger any action in the Run Now tab in those cases and the report would only start when you selected one of the Quick Range buttons.

We fixed an issue where sensor graphs did not clearly show gaps in data collection: the graph ended at the timestamp of the last received data instead of extending to the current time, which could make outdated data look recent. The right edge of the graph now always represents the current time, so gaps in data collection are visible at a glance.

• We fixed an issue where triggering a meta-scan for the SNMP HP LaserJet sensor via POST /api/v2/experimental/devices/ID/metascan?kind=snmphplaserjet request failed with the error message: could not unwrap userland response: error 5: TOctMetaRequestOIDLibraryScan.InternalCreateRequestMessage, no value found for libraryname, even though the same meta-scan worked correctly when triggered from the Classic UI.
• We fixed an issue where the GET request for  /api/v2/setting-lookups/ownid resulted in an error and schema warning message in the Core Log: no schema found for lookupid <ownid>. The ownid lookup is now available through the Core BL lookup collection: GET /api/v2/setting-lookups/ownid now returns Ok with a single-column, single-row list carrying the requested node ID.
• We fixed an issue for the SNMP HPE BladeSystem Blade sensor that failed with the message TPaeInternalList.GetData: Col index out of bounds when you created the sensor via POST request /api/v2/experimental/devices/ID/sensor?kindid=snmphpbladesystemserverblade, regardless if the metascan you ran before to discover available blades was successful.
• We now support settings sections for the Probe, Group and Devices PATCH endpoints. You can now execute a PATCH request with the according request body on the devices endpoint for Credentials for NATS and Credentials for Proxmox settings, for example.
• We fixed an issue in the experimental API schemas (GET /experimental/schemas/{id}/post) endpoint, where required integer fields without a default value, such as port numbers or response codes, did not include their valid range. This affected fields include allowedcode (Port sensor), timethreshold (HTTP Push Data sensors), contentwarningtimevalue (IMAP sensor), socksproxyport (SSL/SSL Certificate sensors, for example. These fields now include minimum, maximum, and description information directly in the schema.
• We fixed an issue where POST /experimental/devices/{id}/metascan resulted in a bad request with the error message The request could not be processed. Check if the format and the data types are correct. Cause: required field \"user\" is missing in the request parameters. The issue occurred because the endpoint required an undocumented params wrapper around the credentials fields, so sending the fields described in metascan_body directly as the request body returned HTTP 400 (required field missing).
• We fixed an inconsistency in the API v2 where querying the autodiscovery field for a group and a device returned different results, even when neither had ever run auto-discovery. Groups correctly returned {"active": false, "progress": 0, "last_autodiscovery": null}, while devices incorrectly returned null. Devices now return the same, correct value as groups when no auto-discovery has run.
• We fixed an issue in the API v2 where starting a metascan via POST /experimental/devices/{id}/metascan while a metascan for the same device and sensor kind was already in progress caused the request to hang silently, with no response and no log entries. This endpoint now correctly returns a 400 Bad Request error with a clear message indicating that a metascan is already in progress for that device and sensor kind.
• We fixed an issue for the endpoint GET /experimental/devices/{id}/metascan where the application server did not distinguish between 410 Gone vs 404 Not Found HTTP errors and returned 400 Bad Gateway.
• You are now able to create a Sensor Factory sensor via POST request /experimental/devices/{id}/sensor?kindid=aggregation. Previously, the POST request would fail because of a parsing issue.
• We fixed an issue for sensorcustomlookups that did not work properly for the SNMP Custom Table sensor on the /api/v2/setting-lookups/columns endpoint.
• We fixed an issue for the endpoint /experimental/devices/{id}sensor in the POST section that used kindid as parameter instead of kind.
• We fixed an issue for /api/v2/experimental/devices/ID/sensor?kindid=snmpcustomadvanced POST request where field values for disabled channels were required. For example, disabling a channel via usechannel{N} = "0" did not suppress validation of that channel's other fields, such as channel{N}name, channel{N}oid, and channel{N}valuelookup, which were still incorrectly required.
• We fixed an issue where a meta scan for several sensor kinds, including EXE, EXE/Script Advanced, HL7, ADO SQL v2, and PostgreSQL, could hang indefinitely with no result and no error, up to a one-hour timeout. These meta scans now complete normally, or return a clear error if something goes wrong.
• We fixed an issue where creating a Packet Sniffer sensor via the API failed because the list of available network adapters could not be retrieved. The API now correctly returns the probe's network adapters, so sensor creation works as expected.

We fixed an issue where sending certain API requests (such as SSO login, login, or pausing a sensor) with a literal null body instead of an empty or valid JSON body caused the AppServer to crash and write a panic log file. Such requests are now correctly rejected with a proper HTTP error response.

We currently face an issue that occurs when you create an auto-discovery task in the new UI with a Class C base IP address scanning range, the IPv4 range end field is pre-filled with a default value of 254, but only accepts values between 0 and 5. Clicking Create with the default value in place results in the error The value must be between 0 and 5 (inclusive). As a workaround, manually set IPv4 range end to a value between 0 and 5 before creating the task.

With the change from NATS to QUIC, the NATS Server is no longer installed and the NATS Server tab is no longer available in the PRTG Administration Tool when you run a fresh installation of PRTG. As a result, Multi-Platform Probe (MPP) 3.11.0, which requires NATS Server for its connection, cannot be added on a new install. This issue does not affect updates from PRTG version 26.3.124.1727 to 26.4.126.1824. With the upcoming release of Multi-Platform Probe version 4.2, you will be able to add it to a fresh PRTG installation via QUIC.

• Security: You can verify the authenticity of the PRTG installer with the Secure Hash Algorithms for the following versions and release channels:
  • Stable 26.4.126.1824:
    •  sha256_exe: 61EE94EF1BD219B46C8F7A1B1D46909991465ED3F79FE1CBA50B38057FC63ECC
    • sha256_zip: 53168856EF033D8802D28ED201C50F2B3A829AC0B59283E0040FF024D53D7788

You can try out the experimental SIMATIC S7-300/400 Custom Process Data (BETA) sensor which shows contents of Data Block memory, process image inputs, and process image outputs of a SIMATIC S7-300 or S7-400 controller.

We improved the SIMATIC S7-1200/1500 Alarm Status sensor so that the JSON-RPC support probe to the PLC’s Web API is now issued only once per device, even when multiple S7 sensors on the same device start their checks at the same time. The sensors report protocol not supported when a PLC does not support the JSON-RPC API.

With this PRTG version, we introduce the new FTP Server File Count v2 sensor, a successor to the existing FTP Server File Count sensor, ensuring you can continue monitoring file counts on your FTP server. The sensor connects via an FTP URL, rather than separate host/port settings, and lets you configure recursive subfolder scanning, Passive or Active FTP mode, request timeout, and connection security (Explicit, Implicit, or None). This sensor type supports IPv4 and IPv6.

With this PRTG version, we introduce the new Redfish Fan Status sensor, giving you a single, consolidated view of fan health and speeds for a server via Redfish. This sensor creates the channels Overall Status, (Fan Name) Status and (Fan Name) Speed. You can now replace the SNMP HPE ProLiant System Health sensor with the Redfish sensors (Redfish System Health, Redfish Temperature, and Redfish Fan Status), fully migrating from SNMP to Redfish for HPE ProLiant servers.

With this PRTG version, we introduce the new Redfish Temperature sensor, which lets you monitor individual temperature readings from any Redfish-compliant server. The sensor creates one instance per physical temperature probe, giving you granular thermal visibility and per-sensor alerting instead of a single rollup value. This sensor supports IPv4 and IPv6.

With this PRTG version, we introduce the new SNTP v2 sensor, which monitors a Simple Network Time Protocol (SNTP/NTP) server. The sensor checks the time difference between the target NTP server and the probe's local system time, the server's response time, and its stratum level. Unlike the already existing SNTP sensor, this sensor reports the time offset at millisecond resolution instead of in whole-second steps, making small clock drifts visible so you can set alerts on them. This sensor comes with the channels Response Time, Offset, and Stratum. The sensor supports both IPv4 and IPv6 and is compatible with the Classic probe, the Multi-Platform Probe, and PRTG Hosted Monitor.

With this PRTG version, we introduce the new WMI Network Card v2 sensor, a successor to the classic Windows Network Card sensor for monitoring bandwidth usage and traffic statistics of Windows network interfaces. The sensor uses WMI to track in/out traffic, packet rates, and error/discard counters, helping you detect overloaded links, faulty interfaces, or unusual traffic patterns. The sensor runs on PRTG classic Probe and will be supported on the upcoming Multi-Platform Probe for Windows.

With this PRTG version, we introduce the new WMI Print Queue v2 sensor, a modern successor to the existing Windows Print Queue sensor, letting you monitor print queues on your Windows print server. The sensor discovers print queues and reports the number of jobs in the queue, optionally filtered by a minimum print job age so only jobs older than a defined threshold are counted. You can optionally define custom sensor states (Warning or Down) for specific printer return messages, such as Paper Jammed, Toner Out, or Offline, instead of using the default behavior of ignoring these messages. This sensor works on PRTG Classic Probe and will be supported on the upcoming Multi-Platform Probe for Windows.

With this PRTG version, we introduce the new WMI Windows Security sensor as a successor to the WMI Security Center sensor, which monitors the security status of Windows client systems via WMI by reporting on security products registered with the Windows Security Center, such as antivirus, antispyware, or firewall products. Each sensor reports Product Status as the primary channel, along with Signature Status. This sensor does not run on Windows Server systems, since the Windows Security Center is only available on client Windows versions. This sensor works on PRTG Classic Probe and will be supported on the upcoming Multi-Platform Probe for Windows.

You can now monitor available (free) system memory on Windows using the new WMI Memory v2 sensor. The sensor connects via WMI and provides free memory in bytes and as a percentage, helping you detect low-memory situations before they impact application performance or stability. This sensor will also be supported on the upcoming Multi-Platform Probe for Windows.

You can now monitor the CPU load of Windows systems using the new WMI CPU Load v2 sensor. The sensor gives you full visibility into CPU utilization, both as an overall total and broken down per logical processor core, helping you quickly spot overloaded systems and identify uneven load distribution across cores. This sensor will also be supported on the upcoming Multi-Platform Probe for Windows.

You can now monitor how long a Windows system has been running since its last reboot with the new WMI System Uptime v2 sensor. Use it to detect unexpected reboots early and verify the stability and availability of your systems over time. This sensor will also be supported on the upcoming Multi-Platform Probe for Windows.

With this PRTG version, we introduce the new WMI Pagefile v2 sensor, which monitors the overall usage of the Windows paging file on a device. The sensor shows total pagefile usage in percent, helping you detect memory pressure situations and prevent performance degradation due to excessive paging. The sensor is compatible with the Classic Probe and will be supported on the Multi-Platform Probe for Windows.

We enforced input sanitization on sensor channel names to defend against possible Cross-Site Scripting (XSS).

We improved and sanitized the displayed data in Bad Request error dialogues that occur during data validation when you entered disallowed characters or invalid data.

We performed sanitization on notification message parameters to prevent information disclosure.

We hardened PRTG against possible cross-site scripting (XSS) attacks related to output on error pages.

We improved the log message that is logged in the Log tab when you pause an object indefinitely. Previously, the log message only displayed the status pausing. The log message now also displays paused when the process is finished.

We added an explicit Certificate Validation option to HTTPS-based sensors, giving you control over how strictly certificates are checked. The following sensor groups use strict validation that is now enabled by default: Cisco Meraki, Microsoft 365, Microsoft Azure, Cloud, and Zoom. These sensors will fail if they encounter an untrusted or manipulated certificate. The other sensor groups, as follows, keep the default accept any certificate so existing behavior is unchanged: DellEMC, Fortigate, HPE 3PAR, HTTP v2, NetApp, Orchestra, PRTG Data Hub, Proxmox, REST v2, Redfish, VMware, and Veeam. Please note that on Windows, the Cloud and Zoom sensors (now using strict validation) may fail if the intermediate CA certificate is not directly installed in the certificate store. This is a known limitation and might happen especially if you are using a deep inspection firewall manipulating the SSL certificates.

• We updated the default device templates to use the SNMP CPU Usage sensor during initial auto-discovery in PRTG. Previously, the device templates created the legacy SNMP CPU Load sensor instead of the successor SNMP CPU Usage sensor.
• We have improved certain vendor-specific device templates that were incorrectly applied during Auto-Discovery. Affected device templates were, for example, BuffaloTeraStation or Server Dell. Vendor-specific device templates now only apply when the target device is confirmed to be from the expected vendor.
• We have added a device template for Proxmox sensors that you can use when you update to this PRTG version. The device template applies for the following sensor types: Proxmox VE Container Status sensor, Proxmox VE Cluster Health sensor, Proxmox VE Node Performance sensor and Proxmox VE Virtual Machine Status sensor.
• We updated the device template Printer (Generic) for printer sensors that is used during the Run Auto-Discovery with Template process to use the new SNMP Printer v2 sensor. Previously, the template only discovered and added the former SNMP Printer sensor after you ran an auto-discovery with the mentioned device template.

The Script v2 sensor now supports PowerShell 7 (PowerShell Core) with this PRTG version, letting you run modern scripts that rely on PS 7 features or modules. The sensor now detects and runs PowerShell scripts using a secure script-wrapper environment that disables verbose event logging. Please note that the already existing EXE/Script sensors continue to support PowerShell 5.1, since compatibility with PowerShell 7 and the old sensors is not given.

• We improved how the Traceroute Hop Count v2 sensor handles route changes. Previously, a route change only triggered a single warning or down status that cleared as soon as the route stabilized, which could hide persistently unstable routes. Now, you can enable the new Notify on Route Change setting to have PRTG create a notification whenever the route changes, giving you a more reliable way to track route instability over time. If enabled, you can also activate Ignore ICMP Timeouts to exclude timeouts from the route comparison.
• We improved the performance of the Traceroute Hop Count v2 sensor on Windows by switching from sequential pings to event-based response handling.

Various other minor fixes and improvements, updated user manual.

We updated the German, Dutch and Spanish language files.

You will see an additional information on the PRTG Setup page for System Status: UVExplorer. This entry is intended to prepare for future releases and currently shows the statuses disabled, unknown, and n/a.

We fixed an issue where sensors that were set to Down (Acknowledged) Indefinitely lost their acknowledged status after a cache recalculation. The issue happened when you triggered a Cache recalculation manually and the acknowledged sensors reverted to Down Status after the Service Restart.

We fixed an issue that occurred in previous Preview version 26.3.123.1654, where the PRTG Core service ran into a read lock in certain cases when you set up a new Multi-Platform Probe using this PRTG Preview version. After adding the NATS Server Access Identifier in the NATS Connection Settings and restarting the Core service, you could observe the following error in the Core.log: The current Thread ran into a timeout after entering a writelock, waiting for readers to leave.

• We fixed an issue where the NATS Manager was not properly uninstalled: if you canceled a PRTG installation while NATS Manager was still installing, and when fully uninstalling PRTG. In both cases, NATS Manager is now correctly uninstalled. Note: a regular PRTG update does not uninstall NATS Manager.
• We fixed an issue where the Core Server service did not start in certain cases due to service dependencies when you updated to PRTG version 26.2.120.1449. The issue occurred when you had a different language then English set as local language on your system and when you had a PRTG version with Database installed.

We fixed an issue for the HTTP v2 sensor that reported an error with the message The sensor could not get a response from the server. 302 (Found) in certain cases. The issue occurred in cases where connections closed by some embedded HTTP servers without sending a proper close_notify were incorrectly reported as an error, even though the response data had already been fully received.

We fixed an issue where the field for Login Header Name was visible when you used None (default) for the Authentication Method in the Credentials for REST API settings. The Login Header Name field is now only visible when you select the option Session-based authentication with Header (default).

We fixed an issue where the NetApp LUN v2 sensor treated the comment field as mandatory, causing sensor creation to fail for NetApp ASA r2 systems, where this field is not present in the LUN REST API response at all.

We fixed an issue for the SNMP Library sensor where it was possible to select the entry Select a file in the Please select a library file pop-up window during sensor creation. Creating this sensor would fail with the error message Nothing was selected, no sensors could be created when you had selected this option.

We fixed an issue for sensors that use a strict certificate validation so that system, group policy or enterprise certificates are now properly imported using the Certificate Validation settings. This fix applies for Cisco Meraki, Microsoft 365, Microsoft Azure, Cloud and Zoom sensor types.

We fixed an issue where the Processes table on the System Information tab remained empty when no SNMP credentials were configured, even though WMI was unavailable and SNMP was able to retrieve values. This issue occurred when you had configured the WSMan protocol for WMI connections before.

We fixed an issue where PRTG Desktop failed to load a device's child sensors when a Ping v2 sensor on that device was in timeout state and returned an INF value for lastvalue_raw. Previously, the API response's non-standard INF JSON value caused an invalid JSON error in PRTG Desktop, leaving the device entry stuck in loading indefinitely, even though the same device and sensor loaded correctly in the PRTG web interface.

We fixed an issue for Device Settings where the Windows Compatibility Options section was displayed twice. The second, shorter section was an obsolete remnant from a previous implementation and was no longer functional. You will now only see one available Windows Compatibility Options section in the Device Settings again.

With this PRTG version, we deprecate the HTTP Full Web Page sensor that we already announced with PRTG Stable version 26.3.122.1665. You cannot add this sensor anew when you update to this PRTG version, however, existing sensor types continue to run. We recommend that you use the HTTP Webpage Sensor (BETA) instead.

With this PRTG version, we deprecate the SSH Disk Free sensor. You can no longer create this sensor type when you update to this PRTG version, however, existing sensor instances continue to run. You will also receive an according TO DO ticket in PRTG. We recommend that you use the successor sensor SSH Disk Free v2 instead. For more information about sensor deprecation and discontinuation, please see our Knowledge Base article: What do deprecation and discontinuation in the context of a sensor mean?

With this PRTG version we discontinue the Common SaaS sensor. We announced the deprecation of the Common SaaS sensor with PRTG version 25.3.110. Please note that existing Common SaaS sensors will stop working when you update to this PRTG version. It is not possible to create a Common SaaS sensor anymore. For more information about sensor deprecation and discontinuation, please see our Knowledge Base article: What do deprecation and discontinuation in the context of a sensor mean?

As of PRTG Stable version 26.3.122.1665, the AI Chatbot Max previously available on the Welcome Page in PRTG New UI is no longer accessible in PRTG until further notice.

We currently face an issue where you cannot edit the License Key or License Name on the /settings/status/license/activation page in the New UI. The License Key or License Name wont be changed when you click on Update License. This issue also affects the option Activation Type that does not display the settings when you selected Manual (offline activation). Please use the PRTG classic web interface in this case when you want to make changes to your license.

You can verify the authenticity of the PRTG installer with the Secure Hash Algorithms for the following versions and release channels:

• Stable 26.3.124.1727:
  • sha256_exe: 59D6A062A230036BD243AE0697090184F75C67C636522FE8C771C785D155378B
  • sha256_zip: B38D66B845C31972ADC3BA0B9E740B234BCAF1A07348FE3B88F00A8569504D4B

With this release, version 26.3.124.1728 is also available, as we are currently executing an A/B test. This version will therefore only be displayed for installation if you are in the corresponding group for a PRTG trial installation via website download. Apart from all changes that are included in 26.3.124.1727, this version comes with improvements and new features for our New UI.

You can try out the experimental SIMATIC S7-1200/1500 Alarm Status sensor (BETA) with this PRTG version, which uses the S7 Web API's Alarms.Browse function to monitor active and unacknowledged alarms on your Siemens S7-1200/1500 PLC, including the critical case where the PLC stays in RUN while a process alarm remains active and unaddressed. The sensor reports the number of unacknowledged active alarms in Unacknowledged Active Alarms as primary channel, alongside total active alarms broken down into program, system, and other alarm categories, and shows the text of the most critical active alarm as the sensor message. This sensor requires Credentials for S7 Web API in the device settings.

• You can now enable the experimental Model Context Protocol (MCP) server, which you can find under overview/index.html#mcp on your PRTG instance and which is exposed as a single endpoint at /api/v2/mcp. This MCP server allows AI assistants and other MCP-compatible clients to interact with PRTG. The /api/v2/mcp endpoint provides the tools, and all non-deprecated endpoints are supported.
• We improved the validation of ReadOnly fields in PRTG API v2 so that an error is returned in the response body when you try to modify or create a ReadOnly field. The type ReadOnly applies, for example, to the field parenttags.
• We added the experimental endpoints /experimental/featureflags and /experimental/license that are now available in the System section of your /api/v2/oas/.
• With this PRTG version, we introduce a new batch DELETE endpoint under /experimental/objects in the APIv2, letting you delete multiple objects, such as probes, groups, devices, or sensors, in a single API call using a filter (e.g. a list of object IDs), consistent with the existing batch pause, resume, and scan endpoints. The response confirms which objects were successfully deleted. If some objects cannot be deleted due to missing permissions or other issues, the response details which IDs succeeded and which failed along with the reason.
• We fixed an issue where creating a sensor via /experimental/devices/{id}/sensor returned a Location header pointing to /experimental/sensors/{id}, which did not correspond to any existing endpoint in the application server. The Location header now correctly points to /sensors/{id}.
• The /experimental/users and /experimental/users/{id} endpoints now include the user's role information, matching what the deprecated user overview endpoint already provided. The role is reported as READONLY, READWRITE, or ADMIN.

We introduce a new feature Alarm Insights in the New UI. It is available on the left side menu bar. The feature helps you analyze alarms, acknowledge them directly, and get suggestions on how to resolve them. Alarm Insights is currently available as an early access preview. You can sign up to participate via a link that takes you to the registration page.

• You can now select your remote probe in the Probe drop down menu for creating an Auto-Discovery Task. Previously, the remote probe could not be selected in the Probe drop down menu and you were not able to create an Auto-Discovery Task for it.
• We fixed an issue where deleting a device or group left its Auto-Discovery Task behind as an orphaned entry in the Auto-Discovery overview. Deleting a device or group now automatically removes its associated Auto-Discovery Task. Tasks belonging to other, unaffected nodes are left untouched, and moving a node to another group no longer deletes its task, which continues to point at that node as expected.
• We fixed an issue where editing an existing Auto-Discovery Task and saving the changes did not close the Edit Task window. After saving changes to a task, the window now closes automatically and returns you to the Auto-Discovery Overview.
• The Auto-Discovery Task name field is no longer pre-filled. To prevent duplicate task naming, you must now enter a unique name manually when creating a new task. This change applies to all entry points for creating Auto-Discovery Tasks.
• We fixed an issue where creating a new Auto-Discovery Task with Windows Credentials did not actually apply those credentials during auto-discovery. As a result, devices were discovered with far fewer sensors than expected.
• We fixed an issue where the discard-changes confirmation dialog, shown when navigating away from an Auto-Discovery task or when you clicked Cancel with unsaved changes, did not appear centered in the viewport.
• We fixed an issue where the Scanning range was not displayed correctly for Legacy Auto-Discovery Tasks. Previously, the Scanning range displayed 1-254 as default for all legacy auto-discovery groups. The Scanning range now displays the correct IP range for auto-discovery groups. For auto-discovery with a device only as target type, the Scanning range will show -.
• You will no longer see the Review state of Auto-Discovery Tasks in the Auto-Discovery overview as it runs in the background. Additionally, you can no longer select the Pending Review checkbox from the Status drop down menu.
• We fixed an issue where creating an Auto-Discovery Task with a list of multiple IP addresses and/or DNS names (IPv4 and IPv6) did not work correctly, even though the task was created and displayed in the UI. Previously, the scanning range was shown without commas separating the individual IP addresses or DNS names, and discovery only actually worked when a single address or DNS name was entered.
• We improved the text displayed in the pop-up dialog Delete auto-discovery task? that shows when you want to delete an Auto-Discovery Task.
• We fixed an issue where creating an Auto-Discovery Task with a specific device template did not correctly reflect this setup in the resulting Auto-Discovery group settings. Previously, these settings incorrectly showed No auto-discovery (default) or Detailed auto-discovery instead of Auto-discovery group/device with specific device template with the selected template marked.
• We fixed an issue where adding a Remote Probe with Auto-Discovery Task showed its target object in the Auto-Discovery Overview as generically named Group instead of Network Discovery.
• We fixed an issue where it was not possible to delete an Auto-Discovery Task created on the Local Probe.
• We fixed an issue in the New UI where running sensor recommendation was displayed as auto-discovery in the Active Background Tasks growl message.
• We fixed an issue in the New UI that occurred when you started an auto-discovery manually on a device while the initial auto-discovery was running. In the previous PRTG version, you did not receive the message Auto-Discovery pending anymore for auto-discoveries that were triggered but not yet started and which you ran manually on a device.
• We fixed an issue where users without admin rights, for example read-write access users, could not see their Auto-Discovery Tasks properly. Read-write users now see their Tasks in the Overview correctly, as long as they have the matching rights on the monitored probes, groups, or devices.

You are now able to simulate an error status via context menu Simulate error status for sensors. Once a sensor is in simulated error state, resuming it clears the simulated error.

With this PRTG version, we introduce the new Dependencies view in the New UI, so you can review your objects' dependency tree without switching to the classic interface. A new Dependencies entry in the main navigation takes you to an overview page with three tabs — Overview, Selected Dependencies, and Master Dependencies — and you can click any object in the graph or tables to jump directly into its dependency view.

We fixed an issue where in certain cases submitting forms that use iFrames in the New UI briefly displayed the classic PRTG interface in the background.

You can now access Libraries directly from the main navigation menu in the New UI. The new Libraries entry is placed between Monitoring and Maps and loads the Libraries page in the main content area. The Management tab is visible to read/write users only. The History tab requires admin rights. The right-click context menu is available on Library and Library Node objects in the Overview tab only.

We fixed an issue in the Map Designer where clicking on objects in a Data Table did not navigate correctly within the New UI. Previously, clicking a sensor's graph opened the sensor overview in the classic UI instead of the sensor's Graphs page in the New UI, and clicking on other objects resulted in a Something went wrong while loading the content error.

We fixed an issue where the mobile navigation header (hamburger menu) disappeared entirely when navigating into the Auto-Discovery Tasks module on a mobile device. The navigation header is now visible on all Auto-Discovery Tasks routes, so you can always open the main menu and navigate elsewhere, even though this module still shows a Not available on mobile message in the content area.

With this PRTG version, you can now use the Search option in the New UI, letting you search all your objects from anywhere in the interface and jump straight to a device, sensor, report, or ticket by name instead of navigating the object tree. A search input is now available in the header on every page; submitting a search takes you to a dedicated results page. The page also shows a loading state while searching, a hint when no term is entered, and an empty state with a quick way to clear your search and filters when nothing matches.

The primary channel of a sensor is now correctly displayed in the New UI when you changed it before in the Sensor Display settings in the PRTG classic interface.

You can now use the Recommended sensors feature in the New UI that is displayed on the sensor Overview page and which is available also via context menu. You can trigger the action by clicking on Recommend now. You can trigger a scan at any time to refresh recommendations, with a spinner shown while the scan is in progress, and an empty list if no recommendations are available. A success or error toast confirms the outcome after installing sensors.

We fixed an issue in the popup window for editing Schedules where saving with an empty Schedule Name field correctly blocked the save and showed the This field is required. validation error, but incorrectly also displayed the Settings have been saved. success toast at the same time. Now, only the validation error is shown when a required field is missing, and no success toast appears.

With this PRTG version, we introduce Insights, bringing the Top 10 Lists feature into the New UI. Insights appears as a new tab in the right-split layout monitoring view for Groups and Probes. From this view, every table link takes you to the Root Group's right-split layout monitoring view showing the correct sensor table, so you can move seamlessly from an overview straight into the relevant sensors.

With this PRTG version we introduce the new IP Reputation Score sensor, which is the successor to the IP on DNS Blacklist sensor. This new sensor lets you check whether the IP address of a device is listed on DNS-based blacklist servers (DNSBL). The sensor supports both IPv4 and IPv6 and is compatible with the Multi-Platform Probe.

You can now monitor network jitter also on the Multi-Platform Probe without requiring the .NET framework, using the new Ping Jitter v2 sensor. It supports IPv4 and IPv6 and provides four monitoring channels: Jitter (ms), Minimum, Average, and Maximum Response Time (ms). You can configure the timeout, ping count, ping delay and time to live. If no ping replies are received, the sensor reports an error message accordingly.

With this PRTG version we introduce the new Proxmox VE Cluster Health sensor that left its BETA status and is now fully supported. This sensor monitors the health status of Proxmox VE clusters. We introduced this sensor type as experimental BETA sensor with PRTG version 26.1.118.1380.

With this PRTG version we introduce the new Proxmox VE Container Status sensor that left its BETA status and is now fully supported. This sensor monitors performance metrics and status of LXC containers on Proxmox VE clusters. We introduced this sensor type as experimental BETA sensor with PRTG version 26.1.116.1498.

With this PRTG version we introduce the new Proxmox VE Node Performance sensor that left its BETA status and is now fully supported. This sensor monitors performance metrics and status of Proxmox VE host nodes. We introduced this sensor type as experimental BETA sensor with PRTG version 26.1.118.1380.

With this PRTG version we introduce the new Proxmox VE Virtual Machine Status sensor that left its BETA status and is now fully supported. This sensor monitors performance metrics and status of QEMU virtual machines on Proxmox VE clusters. We introduced this sensor type as experimental BETA sensor with PRTG version 26.1.116.1498.

With this PRTG version we introduce the new REST JSON Data sensor that left its BETA status and is now fully supported. This sensor accesses a Representational State Transfer (REST) application programming interface (API) endpoint and retrieves JavaScript Object Notation (JSON) encoded data. We introduced this sensor type as experimental BETA sensor with PRTG version 25.3.110.1313.

With this PRTG version we introduce the new RDP Client-Side Check sensor, which is the successor to the RDP (Remote Desktop) sensor. This sensor monitors the availability and response time of the RDP service on Windows systems. It establishes a TCP connection to the configured port and measures the time until the connection is accepted. It performs no authentication but it verifies the RDP handshake via the initial server packet. Please note that this sensor type does not support TLS connection.

With this PRTG version we introduce the new SSL/TLS Security Check sensor that left its BETA status and is now fully supported. The SSL/TLS Security Check sensor monitors the security of a connection secured by Secure Sockets Layer (SSL)/Transport Layer Security (TLS). We introduced this sensor type as experimental BETA sensor with PRTG version 26.1.118.1380.

With this PRTG version we introduce the new SSL/TLS Certificate sensor that left its BETA status and is now fully supported. This sensor monitors the certificate of a connection secured by Secure Sockets Layer (SSL)/Transport Layer Security (TLS). We introduced this sensor type as experimental BETA sensor with PRTG version 26.1.116.1498.

With this PRTG version we introduce the new SNMP Custom v2 sensor that left its BETA status and is now fully supported. The SNMP Custom v2 sensor monitors a single parameter that is returned by a specific object identifier (OID) or Abstract Syntax Notation One (ASN.1) Management Information Base (MIB) via the Simple Network Management Protocol (SNMP).

With this PRTG version we introduce the new SNMP Traffic v2 sensor that left its BETA status and is now fully supported. The SNMP Traffic v2 sensor monitors bandwidth and traffic on a device via the Simple Network Management Protocol (SNMP). We introduced this sensor type as experimental BETA sensor with PRTG version 23.3.88.1393.

With this PRTG version we introduce the new SSH Script v2 sensor that left its BETA status and is now fully supported. This sensor connects to a Linux/Unix system via Secure Shell (SSH) and executes a script file that is located on the target system. This sensor type is the successor sensor of the SSH Script sensor. We introduced this sensor type as experimental BETA sensor with PRTG version 25.2.108.1358.

With this PRTG version we introduce the new Traceroute Hop Count v2 sensor that runs also on the Multi-Platform Probe without requiring the .NET framework. This sensor reports the number of hops from the probe to the parent device, displaying the full route in the sensor message so you can immediately see any path changes. If the parent device is unreachable, the sensor goes into a down state with a meaningful error message. The sensor supports IPv4 and IPv6 and is compatible with both Classic Probe and Multi-Platform Probe. Please note that this sensor does not yet support the If Route Changes sensor setting like the already existing Traceroute Hop Count sensor.

You can now monitor the performance of your Microsoft SQL Server instance with the new WMI Microsoft SQL Server sensor. The sensor supports SQL Server versions 2005–2025, including multiple parallel installations, and works on Classic Probe and will be supported on the upcoming Multi-Platform Probe for Windows. Please note that this sensor type only supports WSMan protocol for WMI connections.

With this PRTG version we introduce the new WMI Volume v2 sensor that monitors free disk space on a single Windows volume, including drives, logical volumes, and mount points. This sensor type is the successor to the WMI Volume and WMI Free Disk Space (Multi Disk) sensor. Please note that this sensor type only supports WSMan protocol for WMI connections.

With this PRTG version we introduce the new VMware Datastore (REST) sensor that monitors the disk usage and availability of VMware datastores via the vSphere REST API. One sensor instance is created per datastore and serves as an alternative to the existing VMware Datastore (SOAP) sensor. The sensor reports free space, available capacity, accessibility status, datastore access mode, VM count, disk count, and VM power states. The sensor enters an error state when the datastore becomes inaccessible, the API is unreachable, or authentication fails.

We changed the error message handling for EXE/Script and EXE/Script Advanced sensors. PRTG will no longer print error messages in the sensor message. Please check your sensor logs in case of errors with your custom scripts.

We hardened PRTG against possible Cross-Site Scripting (XSS) attacks in terms of channel names and lookup values.

With this PRTG version we improve the PRTG Installer process for NatsManager updates. If the PRTG installer detects a new NatsManager version, it now takes a snapshot of the current configuration, saves the old binary, and replaces it with the new one without deleting or reconfiguring the existing setup. This eliminates the previous full uninstall and reinstall of the entire NATS system including the NatsServer.

We now support the Acknowledge Automatically option for all sensors in the Scanning Interval sensor settings. This option supports Show down status on error (default) and Show down (acknowledged) status on error.

With this PRTG version we added HTTP Proxy support for the SSL/TLS Security Check sensor and SSL/TLS Certificate sensor. The sensor will use the HTTP Proxy server settings if you have configured them in the device settings.

Various other minor fixes and improvements, updated user manual.

We updated the German, Spanish, French, Portuguese, Russian and Chinese language files.

We updated the German and Spanish language files for certain sensor types.

Your Database Health (Autonomous) sensor will be removed from your PRTG installation when you update to this PRTG version or future versions. The Database Health (Autonomous) sensor was created upon installation of PRTG version 26.1.118.1380 that includes the PRTG Database. With PRTG version 26.2.120.1449, we have already removed the files and components from the PRTG Database which will no longer be installed for new installations.

With this PRTG version your existing custom device templates will be migrated for the following sensor types to their successor sensors: SNMP System Uptime (SNMP Uptime v2), SSH Disk Free (SSH Disk Free v2) and SNMP Memory (SNMP Memory v2) sensor. PRTG will store a copy of the original device templates in the folder PRTG Network Monitor/devicetemplates/backup. The migration happens when you update to this PRTG version. For more information about device template migration, please see our Knowledge Base article: https://helpdesk.paessler.com/en/support/solutions/articles/76000085400-what-is-a-sensor-or-device-template-migration-

New PRTG installations now use WSMAN as the default monitoring protocol instead of DCOM. Existing installations continue to use DCOM without any changes, and you can switch to WSMAN at any time using the new global activation toggle in the UI. PRTG will also create a To-Do ticket for existing installations, informing you that WSMAN is now the default for new setups, that Kerberos is available.

PRTG will uninstall the PRTG (PostgreSQL) Database and its files and components when you update to this PRTG version and if you have previously installed the PRTG version 26.2.118 that includes the PRTG Database. This update process, which involves removing the PRTG Database, only occurs if you have not activated the PRTG Database. If the PRTG Database is activated and contains data, you will receive a message in the installer explaining the next steps when you update to this version.

The Core & Probes tab in the PRTG System Administration section is now divided into two clearly separated sections, Core Server and Probes, so you can easily distinguish which settings apply to the PRTG core server and which apply to PRTG probes. This change also applies to the PRTG New UI.

After activating your PRTG license and restarting the Core Service, successful license activations are no longer incorrectly logged as errors in Core.log. Previously, a successful activation triggered a misleading error entry such as Error during activation of license [...]: Activation was successful. This issue occurred only at the DEBUG log level.

We fixed an issue where renaming a Multi-Platform Probe in the PRTG UI was reset to the default name after a Core server restart. If you renamed your probes you would unexpectedly see the changes reverted in previous PRTG versions. The name you set in the PRTG UI now always takes precedence, even if the name is later changed in the MPP configuration, the UI name is retained. Please note that this fix also applies to classic probes, which will no longer revert to their connection-time name when renamed during an active connection.

We fixed an issue that occurred when you updated from an older PRTG version, i.e. 26.1.116.1498, to PRTG version 26.1.118.1380 or later where the NATS server certificate could not be imported in certain cases. The update would fail with a NATS setup error in the installer. The issue only occurred if you had PRTG installed with a non-integrated NATS server, that is prior to version 26.1.118.1380 and you updated to a newer version.

You can now use again the option Create Configuration Snapshot under the section Administrative Tools for the PRTG Core Server in PRTG. In previous PRTG versions, the button Go! did not trigger any action to create a configuration snapshot in the Configuration Auto-Backups folder.

• We have improved the PRTG installer that displayed a command window for a short moment when external commands or programs were called, like for the PostgreSQL database.
• We fixed an issue where the links for our terms and conditions and privacy policy redirected to the English web page when running the installer in German.

After an unexpected SSH disconnection, the SSH Script v2 sensor now correctly uses the newly established SSH session for all subsequent scans. Previously, after a successful reconnect, the probe fell back to the previous session object, causing repeated authentication failures (e.g., ssh_userauth_publickey: Out of memory) every 60 seconds with no automatic recovery. A possible workaround was to manually pause and resume the sensor.

We fixed an issue where only the first created sensor name instead of the sensor type was displayed in the Create Template Results pop-up window after template creation. This issue happened, for example, for the SNMP Traffic v2 or Microsoft 365 Service Status Advanced sensor where more than one sensor is created.

When using the HTTP v2 sensor with the POST request method, you can now set a custom Content-Type header (e.g. application/json) and the sensor will correctly apply it to outgoing requests. Previously, the sensor ignored the configured value and always sent application/x-www-form-urlencoded instead.

We fixed an issue that occurred in the authentication process of the Network Share sensor to the remote server.

We fixed an issue for the Redfish Power Supply sensor that reported an error with the message The requested resource was not found on the remote server after an HPE iLO firmware update to version 1.22.00 in certain cases.

We fixed an issue where using Auto-Discovery with a template to create the SSH Disk Free v2 sensor produced one separate sensor per Linux mount point, each containing all detected mount points as channels. PRTG now correctly creates a single sensor with one channel per mount point.

We fixed an issue where it was possible to click an Add sensor button for the PRTG Core Server device, which resulted in an error with the message: Autonomous objects do not support this operation. The Add sensor button is now hidden for devices that do not support this option. We fixed this issue also in the New UI.

You can now use the Show as Gauges view on the Alarms page as expected. Previously, switching to this view resulted in a blank page showing raw JSON data instead of gauge widgets. This affected any sensor that included HTML content in its status message.

We fixed an issue where Chromium-based browsers experienced significant delays or timeouts when loading pages in the Classic PRTG Web UI. The issue was caused by certain Chrome extensions using postMessage to communicate with the application, a confirmed example is the Angular DevTools extension. Firefox was not affected. You can now use Chromium-based browsers with extensions installed without experiencing indefinite loading times.

The configuration file of this version is not downwards compatible with previous PRTG versions.

We currently face an issue where the Windows Compatibility Options section is displayed twice. The second, shorter section is an obsolete remnant from a previous implementation and is no longer functional. Any settings configured in this second section will not be applied to any sensors. As a workaround please use the first Windows Compatibility Options section that appears on the page. This is the only section that is active and where your configuration will be correctly applied. We will deliver a fix for this issue with a future PRTG version.

We currently face an issue where logging in via Single Sign-on results in a 404 error when you use a non-default (custom) HTTPS port for the Web UI. Instead of preserving the configured custom port after the login callback, SSO login redirects to the default port (443) in those cases. This can cause the request to hit the wrong service (e.g. the probe port) and result in an error. We will provide a fix for this issue in an upcoming PRTG version.

With this PRTG version we announce the upcoming deprecation of the HTTP Full Web Page Sensor. You cannot add this sensor anew when you update to upcoming PRTG version 26.x.123, however, existing sensor types continue to run. We recommend that you use the HTTP Webpage Sensor (BETA) instead. You will receive an according PRTG TO DO ticket when you update to this PRTG version.

You can verify the authenticity of the PRTG installer with the Secure Hash Algorithms for the following versions and release channels:

• Stable 26.3.122.1665:
  • sha256_exe: D92057E6A451CD7D811837134941CA8649F3A93290360E92AF0C81DBC6526CC5
  • sha256_zip: 82878C995877FB0F5882D1BC988B486E2AC48BDC4D1D0510226665FA780D3969

You can now monitor the complete loading time of web pages, including all resources such as images, scripts, and stylesheets when you try out the experimental HTTP Webpage (BETA) sensor. This sensor is the successor to the existing HTTP Full Web Page sensor. The sensor uses a headless Chrome browser on the probe machine to load the requested URL and alerts you when loading times exceed defined thresholds. This sensor also supports the Smart URL Replacement feature, which adds the device host in the URL field of a HTTP sensor automatically when you enter https:///.

You can try out the experimental SIMATIC S7-1200/1500 CPU Status sensor that monitors the operating state, cycle times, and load of Siemens SIMATIC S7-1200 and S7-1500 PLCs via the S7 Web API (JSON-RPC). This sensor automatically detects firmware capabilities and redundant CPU configurations, cycle time and load channels only appear when the device reports them, so older firmware is supported gracefully. Available channels are Operating Mode, Mode Selector, Cycle Time Events, for example. The channels Operating Mode (R2) and Mode Selector (R2) are dynamically created when redundancy is detected. Please note that the SIMATIC S7-1200/1500 CPU Status sensor does not work on S7-1200 G1 devices because of the S7 Web API integration. This sensor supports S7-1200 G2 PLCs.

You can try out the experimental WMI Service v2 sensor that is the successor to the WMI Service sensor. You can select the services during sensor creation. The sensor will report if services are stopped or paused. If you want to use WSMAN for WMI connection, please make sure to enable WSMAN protocol on the target device. Please note that this sensor type only supports WSMan protocol for WMI connections and that the option to change the Preferred Data Source in the Windows Compatibility Options is not available for this v2 sensor type. If you want to use a non-administrator Windows account for WMI monitoring via the WSMan protocol, please see the Knowledge Base article: https://helpdesk.paessler.com/en/support/solutions/articles/76000088235

With this PRTG version we introduce the new Auto-Discovery Job that lets you manage all your Auto-Discoveries and review their outcomes from one central place in PRTG. You can now create, edit, and delete Auto-Discovery Tasks directly from the overview page. Use the new button Create Task to create a task under any probe you have write access to. The button is grayed out if you have no write permissions on any probe. Required fields are validated, and you are redirected to the overview after a successful creation. Please note that this feature currently only works if you are logged in as a user with administrative user rights for the local probe.

We fixed an issue where it was possible to create a group via Add Group button in the action items without entering a value in the mandatory fields. The settings window was closed after you clicked create and an error would occur: The validation of at least one of the new objects failed because of the following: IPv4 Base: Required field, not defined. The object was not created.

The dependency field now displays the root of the dependency chain. Previously, the dependency of an object was only displayed to its immediate dependency.

We fixed several issues with the approval flow for unapproved probes in the device tree. Previously, the Approve and Deny buttons reappeared after approving or denying a probe instead of disappearing. They now correctly disappear after approval and the sensors and devices of that probe become visible as expected. The buttons now remain visible under an unapproved probe regardless of whether the tree node is expanded or collapsed. The approval or denial notification is also restricted to users with Write permission and pops up immediately upon login if an unapproved probe is present.

We reduced the loading time for iframes on the PRTG System Settings page in the New UI.

• We reordered the tabs across Probes, Groups, Devices, and Sensors sections to follow a logical, usage-based sequence. Tabs are now grouped by relevance, so you can find the most relevant information faster.
• You can now access system information directly from the device detail page in the New UI via the System Information tab. Please note that this tab is not available on mobile view.
• You can now view and edit comments directly on Probe objects in the New UI, bringing Probes in line with Devices and Groups. Opening the Comment tab loads the current comment, and saving persists your changes immediately. The Save and Discard buttons are disabled when there are no unsaved changes.
• We fixed an issue where the History tab appeared twice in the submenu on Probe and Group detail pages, once between Logs and Settings, and once again as the last item after Comments. Both entries linked to the same view. The History tab now appears exactly once in its correct position between Logs and Settings on both page types.
• We added a new Messages tab that is now available on the sensor detail page for sensors that collect message data, such as the Syslog Receiver and SNMP Trap Receiver sensor.

The New UI now surfaces Toplists for all sensors that support them. You can view and navigate Toplists directly from the sensor overview and a dedicated Toplists tab. Sensors that support Toplists are, for example, NetFlow v5, sFlow sensor, IPFIX sensor and Packet Sniffer sensor. An Add Toplist button is available on the Toplists detail page to create new Toplists for the sensor.

• Read-write and read-only users can now see and navigate all objects they have access to in the New UI device tree. Previously, these users had no access to any objects in the device tree despite having the correct permissions assigned.
• We have improved the user rights for read only and read/write users regarding the Copy function via context menu of an object.

As of PRTG Stable version 26.3.122.1665, the AI Chatbot Max previously available on the Welcome Page in PRTG New UI is no longer accessible in PRTG until further notice.

• We fixed an issue for the /experimental/probes endpoint where the filter for status=connected did not work and returned a 400 bad request error in the response body. The issue occurred when you executed a GET request on /api/v2/oas/ for the mentioned endpoint.
• We fixed an issue in PRTG API v2 for the endpoint /devices/{id} that returned a partially wrong response for GET requests on devices that did not have inherited access rights.
• We fixed an issue in the /experimental/sensor/{id} endpoint where the channelgroup.primarychannel field used different formats between GET and PATCH operations. Previously, GET responses returned the full channel ID format while PATCH requests required only the short channel index, forcing you to manually extract and transform the value before using it.

We have replaced the following PRTG API v2 endpoints that were already announced as deprecated in the Open API Specification: probes/{id}/overview, groups/{id}/overview, sensors/{id}/overview and channels/{id}/overview. Those endpoints were replaced with probes/{id}, groups/{id}, devices/{id}, sensors/{id} and channels/{id}. Please note that the endpoints marked as deprecated will be removed in the future. In course of this, the Lookups endpoint will move to the Channels endpoint /experimental/channels/lookups/.

We fixed an issue for the Syslog Receiver sensor that did not receive and display Syslog messages anymore in the previous PRTG version when you had configured Syslog messages with notification template Send Syslog Message.

We fixed an issue that caused gauge widgets to stop rendering in the sensor overview and on maps in certain cases when the target device for that sensor was not reachable and the sensor was in Down status. The issue happened, for example, for the Ping v2 sensor that measures float values and that could report non-numeric values (NaN or INF) when a monitored target became unreachable.

You can now fully access the Custom HTML map item properties in Map Designer again when you update to this PRTG version. Previously, selecting the Custom HTML option in the Properties panel caused an endless loading state, preventing the HTML fields from appearing.

You can verify the authenticity of the PRTG installer with the Secure Hash Algorithms for the following versions and release channels:

Stable 26.2.120.1477

• sha256_exe BB4D22183C3DE6C4FC15E5984765E05DA4273733A9C76DC2008B31619F263BFE
• sha256_zip AB84E8DADA0373F6299D101F9953BB93EC75E98E50997B82E5E924FE272763FA

With this PRTG version we introduce the new SNMP Custom String v2 sensor that monitors a string returned by a specific object identifier (OID) via the SNMP. The sensor interprets the SNMP value returned by the OID as a string, a MAC address, or an IPv4 address and shows the interpreted value in the sensor message. We introduced this sensor as experimental BETA sensor with PRTG version 26.1.116.1498.

We added the new SNMP Printer v2 sensor to monitor printer status, consumables, and operational metrics via SNMP. The sensor supports IPv4 and IPv6. Depending on the monitored printer, the sensor creates the channels Total Pages Printed, Cover Status, Tray Status and Supply Status. The sensor message displays the printer console output. If no printers are defined in the device table, the sensor will report an error. This sensor introduces 1-based numbering for printer units, as well as removing ranged lookups in favor of direct percentage and lookup values.

With this PRTG version we introduce the new SNMP RMON v2 sensor that was rewritten to work also on the Multi-Platform Probe. The SNMP RMON v2 sensor monitors traffic on a device using the Remote Monitoring (RMON) standard via SNMP. In the Specific Sensor Settings you have the option to edit the settings Description or 64-bit on request. This information is collected during sensor creation and if 64-bit counters are enabled in the compatibility settings.

With this PRTG version we introduce the PRTG Installation Report, a new built-in report available by default in all standard PRTG installations under Reports menu. With this report you can collect data about your PRTG installation, including license information, system health and optimization recommendations. The report can be generated on-demand or scheduled for automated delivery. The report supports PDF, CSV and HTML formats.

• We performed sanitization on HTTP error responses to prevent information disclosure. CVE is still pending.
• We performed sanitization on the URL Path in HTTP error responses to prevent information disclosure. CVE is still pending.
• We enforced input sanitization on object name parameters to defend against possible Cross-Site Scripting. CVE is still pending.
• We hardened PRTG against possible cross-site scripting attacks through certain parameters on the public login page. CVE is still pending.

For more information, please refer to the following Knowledge Base article: Vulnerabilities in PRTG prior v26.2.120.1449 | Paessler Knowledge Base

The Microsoft 365 Mailbox sensor now supports the setting Validate Latest Email, like for example, the IMAP sensor. The sensor will use the latest email from the filtered messages. If no filters are configured, all messages are taken into account. You can configure warning or error states based on the Subject, From or Body settings. Additionally, you can set the sensor to Down or Warning status based on age for the latest email.

Various other minor fixes and improvements, updated user manual.

In case of a manual update to this PRTG version and if you have previously activated the PRTG Database, you will see an installation window with the message that the installation has stopped in order to keep your existing data. This is due to a new schema update in this PRTG version. The installation window will provide further instructions on how to proceed with the update.

The auto-update process will currently stop when you update to this PRTG version if you have previously activated the PRTG Database and have existing data. This issue affects you if you have set your auto-update to Automatically download and install in the Software Auto-Update settings. PRTG will create a TO DO ticket Error: The update cannot continue due to a change in the database schema if you run into this issue. For more information, please see our Knowledge Base article: https://helpdesk.paessler.com/en/support/solutions/articles/76000088264

We updated the list and location of the example scripts for custom sensors in the PRTG program directory. This removes all Demo scripts from the pre populated custom scripts directory. Scripts that were not deemed as risky are preserved under the examples script directory. Additionally, we have updated the example scripts for Script v2 to follow a more modern structure. Please note that in course of this change that we removed any .dll and .exe demo binary from PRTG.

To be consistent with our changes in PRTG version 26.1.118.1380 to display information about sensor usage and licensing in the New UI, we removed the Number of Sensors part under License Information on the PRTG System Status page.

We fixed an issue where in certain cases an enabled Geo Map could lead to ajax timeout errors or slow performance in the PRTG web interface. You could observe this issue when your PRTG core server was blocked in your firewall for outgoing connections and PRTG would try to reach the geolocation service continuously. A possible workaround was to disable Geo maps.

NATS setup

We fixed an issue where in certain cases an enabled Geo Map could lead to ajax timeout errors or slow performance in the PRTG web interface. You could observe this issue when your PRTG core server was blocked in your firewall for outgoing connections and PRTG would try to reach the geolocation service continuously. A possible workaround was to disable Geo maps.

We fixed an issue where the PRTG core service used a large amount of memory in rare cases which caused the system to run out of memory in the end. You could find the error message out of memory in the core log file in such cases.

We fixed an issue for the NetApp SnapMirror v2 sensor which regularly went into an error state and did not return any values for certain channels. The ONTAP API omitted transfer fields for continuously synced relationships and the sensor would handle the missing values as error. The issue happened when you used ONTAP with SnapMirror Active Sync and Consistency Groups.

We have improved the DNS v2 sensor regarding filtering reliability and result consistency. Null MX records are now correctly displayed as 0 if a domain does not accept emails, and DNS records of the same type are now sorted alphanumerically to ensure consistent output across repeated requests. Record values are trimmed before filter matching to prevent whitespace-related mismatches. A new Match the full result exactly filter mode has been added for record types whose values naturally contain commas, such as TXT and NAPTR. The internal connectivity check now queries the root domain for NS records instead of using a localhost ANY query, improving compatibility with modern DNS servers.

• We fixed an issue where having multiple ping sensors targeting the same host caused all raw ICMP sockets to receive all answers, resulting in an error message Received packet had unexpected identifier or sequence number in the Result of Sensor logfile. The sensor also wrongly reported packet loss in case of packets received with a mismatching type or identifier.
• You are now able to use a new setting for the Ping v2 sensor Error Status Handling, to define an evaluation method to display negative results. The sensor immediately shows the Down status based on channel lookups for the setting Enter the down status immediately (default).

We fixed an issue where Run Auto-discovery with Templates led to an error (bad request) when you selected device templates via multi edit. Previously, it was only possible to select device templates on the first page of the pop-up window. As soon as you selected a device template on the second page or beyond, an error message appeared stating no device template had been selected.

We fixed an issue for Desktop Client and MultiBoard related API keys that you can create in PRTG via Add API Key for PRTG MultiBoard button. The issue happened when you started the Single Sign-on login flow calling getdesktoptoken.htm. The API key that was returned from the endpoint did not work for Single Sign-on content in those cases.

We currently face an issue where it is not possible to log in via Single Sign-on after enabling PRTG Database for data migration. If you have set up Single Sign-on before and migrated your configuration to PRTG database, the login with Single Sign-on would fail afterwards. In the User Group Settings you could observe that the SSO Group Claim was missing. A possible workaround is to set up a new Single Sign-on user group.

Please note that with updating to this PRTG version, the auto-update process takes longer because it includes the PRTG database and related components, which increase the size of the PRTG installer. We strongly recommend that you do not restart PRTG during this process and wait until the update is complete.

You can verify the authenticity of the PRTG installer with the Secure Hash Algorithms for the following versions and release channels:

Stable 26.2.120.1449

• sha256_exe 62E2681F26E81436A24C2EB0BE26CADEADFD0D529A400FB7DACE806680CCFD83
• sha256_zip A1CE8074AD75B4E06E9567A7EDFC27FDE64D5F83364AB21287FE9AEDA7324236

• We fixed an issue where certificates created by NATS Manager were never deleted from the Windows Certificate Store. The certificates NATS Server for Paessler PRTG and Paessler NATS Manager are now properly removed when PRTG including NATS is fully uninstalled, when an initial installation is canceled or rolled back, or when an update is rolled back to a previous PRTG version without PRTG Database.
• With this PRTG version, the PostgreSQL Database installer will no longer install the pgAdmin tool if you have already installed a PRTG version with the PRTG Database. Your installation will proceed as expected, but the pgAdmin tool will no longer be updated in this case.
• We fixed an issue where setting up the PostgreSQL database with a custom password failed if the password contained certain special characters. The installer now validates both the username and password against the allowed character sets in real time. The PostgreSQL username is restricted to alphanumeric characters only, while the password additionally allows the following special characters: _ ! . + - = ~. An error message is displayed and the user cannot proceed until invalid characters are removed. The setup screen now also clearly displays these constraints to guide users during configuration.
• We fixed an issue when the installation was cancelled in certain cases either manually or due to an error. The PRTG installer will now inform you about the process and the next steps with the message: Roll back of all changes done within this installation finished. Please reboot your system.
• We fixed an issue that occurred if you canceled the installation or rolled back to the previous PRTG version. In that case, the PRTG Administration Tool could no longer be started because the .exe file was no longer present.
• We fixed an issue that occurred in certain cases if you had PRTG installed with a Multi-Platform Probe connected and updated to a PRTG version that includes the PRTG Database. After updating, the NATS service was stopped and could not be started again. Additionally, the NATS server.log file was not created. In the Windows Event Logs you could find the following error: The service did not respond to the start or control request in a timely fashion.
• We have updated our PostgreSQL database from version 18.1 to 18.3.

We fixed an issue where sensor tags were lost after migrating configuration and monitoring data to the PRTG database. This caused sensors to become invisible in tag-based filters, making libraries and reports that rely on tag filtering no longer work as expected. This issue applied to the WMI Free Disk Space (Multi Disk) sensor, for example.

We improved the retry mechanism for the SIMATIC S7-300/400 CPU Restart Overview sensor to reduce false alerts caused by intermittent errors when querying data from a PLC via S7. Previously, the PLC would occasionally return a CPU : Item not available error, causing the sensor to go into a down state for one or more scans before recovering, despite the PLC working correctly the whole time. When the PLC is too busy to serve the request of the sensor, the request is now retried after a delay of 100 ms, with a configurable maximum delay of up to 1000 ms.

• We fixed an issue for the SIMATIC S7-300/400 CPU Status (BETA) and SIMATIC S7-300/400 CPU Restart Overview (BETA) sensor that did not display any data results in certain cases. The issue happened because the sensor did not finish the scan for some monitored PLCs.
• We fixed an issue for the SIMATIC S7-300/400 CPU Status (BETA) and SIMATIC S7-300/400 CPU Restart Overview (BETA) sensor that reported an error message The buffer supplied is too low to accomplish the operation in certain cases. The issue happened for S7-410-5H controllers when the sensor failed to read the diagnostic buffer.

• We added a new setting Numeric Extraction to the Specific Sensor Settings of the SNMP Custom String v2 (BETA) sensor, which allows you to locate numbers inside a string from the SNMP device by using regular expressions. The sensor then displays the result in an additional channel: Extracted Number.
• We have improved the SNMP Custom String v2 sensor by changing the primary channel from Response Time to String Found. The Response Time channel did not display a meaningful error message if you used too many wildcards in the Search String setting. The primary channel String Found will display The search string contains too many wildcards in this case.


Important: To get the new primary channel String Found, you need to create this sensor again.

We fixed an issue for the SNMP Traffic v2 sensor that wrongly displayed 4 GBit/s as a result for unconnected ports in certain cases. The issue happened mostly for SNMP version v1 or high speed interface connections. The sensor will now display the status Unknown correctly for non-available entries instead of a wrong value.

• With this PRTG version we introduce parameter support for the metascan endpoint /experimental/{id}/metascan to create a NetApp System Health sensor via POST request on /experimental/devices/{id}/sensor. The metascan endpoint now accepts a request body with parameters as defined in the schema, allowing the NetApp System Health sensor metascan to be triggered successfully via URL parameters.
• We fixed an issue where consecutive calls to /experimental/schemas/{deviceID} returned inconsistent results for the same sensor. Affected sensors, particularly Dell EMC sensors such as paessler.dellemc.storage_filesystem_v2_sensor and paessler.dellemc.storage_capacity_v2_sensor, could alternately appear as creatable with no hints in one call and non-creatable with a MissingCredentials hint in the next. Consecutive calls to the schema endpoint now consistently return the same results.
• We fixed an issue where the PRTG application server responded with a panic.log file including the message panic: runtime error: invalid memory address or nil pointer dereference. The issue occurred when you executed a GET request on endpoint /experimental/schemas/{parent}/post with parent=40 (local probe) and kind=snmpcustomtable.
• We fixed an issue where the api/v2/settings/public endpoint did not return the correct language upon GET request. Previously, only en-US was returned for the language field. The endpoint will now correctly display the language you have configured in the PRTG webinterface settings.
• We have improved the endpoint /experimental/objects/{id}/clone with better documentation in Swagger UI, for example. The deprecated endpoint clone endpoints experimental/devices/{id}/clone was removed.
• We fixed an issue in PRTG API v2 for the endpoint api/v2/channels/{id} where for some channel items the name field was returned with an empty string.
• We fixed an issue for the /experimental/schemas/{id}/get endpoint that did not handle the readonly property correctly for Read Only users that have the right to acknowledge alarms.
• We renamed the PATCH endpoint to /experimental/sensors/{id} to be consistent with other resource endpoints that use the object plural.
• We have updated the endpoints POST /experimental/devices/{id}/sensor and POST /experimental/devices/{id}/metascan in PRTG API v2 to now support all sensor kinds. Previously, only a selected set of fully tested sensors were allowed. With the sensor creation flow working reliably, the whitelist restriction has been removed, making sensor creation available for all supported sensor kinds without limitations.

We fixed an issue where the Channel Unit Configuration did not display the correct units for Disk size, File size and Memory size.

• We fixed an issue for the Device Tree in the New UI that displayed an additional Add Sensor button when you entered a search string in the search field.
• You can now move devices into different groups and reorder objects within a parent in the new UI. Active monitoring objects are now highlighted across the full row width for better visibility, and a context menu has been added to streamline navigation and management actions.

We fixed an issue for the object tree under Monitoring where object calculation did not work properly for groups that contained only empty objects (groups or devices) and no sensors.

You are now able to use the following Device Action buttons via context menu: Reorder Tree, Copy and Paste. After you have copied an object, a success message appears. The same applies to the object once you have successfully pasted it. If you do not have the necessary access rights to an object, the buttons in the context menu will appear disabled and display the text no permission.

We fixed an issue where in certain cases an unknown error occurred with the message Something went wrong. Please refresh your browser or try again later. The issue in the new UI happened sporadically and in cases when you closed the browser and opened PRTG again with a page using iframes.

• We improved the Home page in wording and display of content to match the user type that is logged in to PRTG.
• You are now able to use our new AI Chatbot Max on the Welcome Page in PRTG New UI. Clicking the Start Chatting button opens a slide-in panel on the right side of the page, where you can interact with the chatbot. MAX AI has in-depth knowledge of PRTG and is ready to assist you with questions and troubleshooting directly from the Welcome Page.