PRTG Release Notes:
Stable Channel

We fixed an issue for Single Sign-on where it was not possible to log in with a Single Sign-on user when you updated to the previous PRTG Stable version 26.1.116.1498 and when you had Single Sign-on configured for your PRTG. The login failed and the page no longer worked. The error message too many redirects was displayed in those cases. If necessary, you may need to clear your browser cache and cookies.

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

Stable 26.1.116.1532

• sha256_exe 5A19643A15A9704C7FDD82DD9B4D9AD8BD4D64E19C1CCB09DCBE44ADEE25AAAD
• sha256_zip 34EAC4DF0428B30C92000AAEA0E483C6ECDE500EB43AF6F313AA26200B5E8CBF

There is an additional installer build 26.2.116.1542 for select distributions, which contains the same content as build 26.1.116.1532.

We have set the HTTPOnly and SameSite flag for the cookies created by PRTG to strengthen secure transmissions.

We improved the security handling for API tokens regarding interactive web sessions by restricting access for API tokens to certain endpoints.

Single Sign-on users are now able to create API keys that can be enabled in the Single Sign-on account settings. As a prerequisite, SSO must be configured in PRTG and an SSO group must exist. You can then enable the new feature Enable API Keys for SSO Users in the Single Sign-on user group settings, which is disabled by default. Additionally, this setting includes a field SSO API Key Lifetime (Days) where you can set the days for how long the API key is valid. When SSO API keys expire after the configured lifetime, the relevant API keys will be cleaned up automatically. As a Single Sign-on user, you can use the SSO API keys also for API authentication.

We have implemented a character limit of 240 characters for the Display Name in the User Account Settings. You cannot save changes if the Display Name exceeds the character limit and you will receive an error with the message The display name cannot exceed 240 characters.

Various other minor fixes and improvements, updated user manual.

We updated the German, Spanish, Dutch and Japanese language files.

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

• We fixed an issue where in certain cases activating an incorrect license key for PRTG Subscription licenses led to access violations in the Core.log file.
• We fixed an issue in the Core.log and CoreActivationLog which created incorrect log entries when you changed the license key in your PRTG. This issue only occurred if you had previously changed the log level to DEBUG. After you have changed the license key, you could see a warning message in the Core.log processing of activation data failed. Furthermore, the license activation success message, for example Startup: Error during activation of license PPEM: Activation successful was logged as error.

• We fixed an issue where the License Name was cut off in certain cases on the License Status page when you did use special characters, in this case quotation marks ", in the license name.
• We fixed an issue for licenses that could happen when you clicked on the Down sensors on the home page to open the sensors list and tried to delete them via multi edit selection. In this case, you would receive an error object not found for those sensors afterwards. Additionally, you could find errors logged in the Core.log as exceptions. The issue also occurred in PRTG when you have activated it on an offline system.

We fixed an issue for Cloud HTTP v2 sensors that reported the error message The queried field "message" is empty in certain cases. The issue also happened when you monitored different endpoints in various Azure regions.

Your DNS v2 sensor now only accepts IP addresses that exactly match the value you configured in the filter. The previous version did not allow exact matching of the results, which could cause false positive results. For example, an IP address matching the filter with one digit more was also accepted.

We fixed an issue for the HPE 3PAR Drive Enclosure sensor that reported an error with the message Invalid response structure encountered, some data is missing. in certain cases. The sensor log also displayed an invalid showcage command. The issue occurred when you used this sensor type for HPE Primera Storage systems.

We fixed an issue for certain HTTP sensors that were missing in the Add sensor list or stopped working in some cases when you updated to a previous PRTG version. This issue has occurred since PRTG version 25.1.104.1946 and affects the following sensors: HTTP Push Data Advanced, HTTP IoT Push Data Advanced and HTTP Data Advanced sensor. In some cases, an error message was logged if you already had HTTP sensors running in PRTG: Could not load "sensor ID: Osk for httppushdataadvanced was not loaded!

We improved the error handling for file system sensors, for example, Dell EMC Unity File System v2 sensor, to better map error messages like The specified network name is no longer available.

We removed the deprecated setting Basic256 in the Security Policy section of the Credentials for OPC UA. This setting was deprecated due to the used hash algorithm Sha-1. Please note that your OPC UA sensors will report an error message if you have configured the Basic256 setting and update to this PRTG version.

We fixed an issue for the scaling factor sensor channel setting where you can enter a multiplication or division scaling factor for sensors with custom units. The issue occurred, when you have configured a scaling factor for your sensor and at the same time entered channel limits. After saving the changes, you could observe that the channel limits were either divided or multiplied with the value you have entered as scaling factor.

We fixed an issue for the SNMP Windows Service sensor that occurred in certain cases when you have used this sensor type in a device template. For example, when you have configured a device template with the SNMP Windows Service sensor and have set an include/exclude filter for a certain service and run an auto discovery later on a device to create the sensors. When you delete one of those sensors afterwards and run the device template again, the deleted sensors would not be created.

We fixed a compatibility issue for Veeam Backup Job Status and Veeam Backup Job Status Advanced sensors that did not support Veeam 13 for Veeam Backup Enterprise Manager and Backup Server. The sensors reported an error with the message that the JSONPath is incorrect in previous PRTG versions.

We fixed an issue for public Maps that displayed an error Map refresh failed when you configured an External Link before in the Map Designer and clicked on the corresponding object in the public map. This issue also occurred with any Sunburst map object that you have added to your map. Opening the links to the individual objects would also lead to an error.

We currently face an issue for Single Sign-on that does not work anymore when you update to this PRTG version 26.1.116.1498. For Single Sign-on configured with Entra ID in your PRTG, you will see the error message The server terminated an operation because it encountered a client request loop, for example. In the browser you could observe too many redirects and that the page is not working in certain cases. We are working on this issue with high priority.

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

Stable 26.1.116.1498

• sha256_exe 79DC26307D0888581E570C74A55532E1EF0713C7D126DD38EBEE516C379473A4
• sha256_zip D7CFAC0F043330460CA7102EF6D9A830817387DE486AFA27BDF96A2CA1166192

You can try out the experimental Proxmox VE Virtual Machine Status (BETA) sensor that monitors performance metrics and status of QEMU virtual machines on Proxmox VE clusters. To use this sensor type, please enter the Credentials for Proxmox in the device settings with API token authentication.

You can try out the experimental Proxmox VE Container Status (BETA) sensor that monitors performance metrics and status of LXC containers on Proxmox VE clusters. To use this sensor type, please enter the Credentials for Proxmox in the device settings with API token authentication.

We implemented a new setting for the SNMP Custom String v2 (BETA) sensor in the Specific Sensor Settings, named Interpret Result as. This setting basically converts the result from the SNMP endpoint into a string. You can select String (default), MAC address and IPv4 address for this setting. The sensor message will then show the format of the setting you have selected before, for example for MAC address it will display "01-02-03-04" as server response.

The Custom v2 sensor now supports string-encoded BITS values, for example MAC addresses, that are converted to a numeric format. Parsed BITS values will work with existing channel configurations.

You can try out the experimental SSL/TLS Certificate sensor (BETA) which is the successor to the SSL Certificate sensor and which was rewritten to also work on the Multi-Platform Probe. This sensor type monitors the certificate of a Secure Sockets Layer (SSL)/Transport Layer Security (TLS) secured connection. Please note that this sensor does not yet support the Use SOCKS proxy setting.

You can try out the experimental SIMATIC S7-300/400 Restart Overview sensor (BETA) that we introduce with this PRTG version. This sensor detects and classifies restart events (cold, warm, hot, planned or unplanned) from legacy Siemens PLCs (Programmable Logic Controller). It helps operations teams understand why and how often a PLC has restarted, which is often critical in diagnosing power losses, software crashes, or watchdog faults. The sensor uses Snap7 and S7 protocol to access the diagnostic buffer of the PLC.

You can try out the experimental SIMATIC S7-300/400 CPU Status sensor (BETA) that we deliver with this PRTG version. This sensor connects to Siemens PLCs (Programmable Logic Controller) using the S7 protocol and reads key diagnostic values like CPU mode (RUN/STOP), OB1 cycle time, cycle load, and recent watchdog events. The data is collected read-only using Snap7 and provides OT teams with remote access to metrics that would otherwise require on-site inspection via TIA Portal.

• We fixed an issue for the endpoints api/v2/experimental/devices and api/v2/devices/{id} where the GET and PATCH results for Access Rights were not updated in PRTG API v2. The Access Rights settings are now updated immediately in PRTG APIv2 after you have created a new user group, for example. Previously, you had to execute another GET or PATCH request to receive the updated results.
• You will now receive a list of creatable sensor types via endpoint /experimental/schemas/{parent} when you have created a group or device before. You will see if a sensor is creatable with the flag creatable=true and the result will contain a list of preconditions that have to be met in order to create the sensor.
• We fixed an issue for the endpoint api/v2/experimental/schemas that did not check if it was valid to add a node to a certain partent ID, in this case the probe ID. For example, when you executed a POST request on this endpoint with parentid=1 and kind=ping, the schema would be returned without an error. Now you will receive an according error code in API v2 in this case asking you to check the ID of the object and that the schema ping does not match parent ID 1.
• We improved the display of settings in the response code so that they correspond to user rights. For example, device settings that are returned via endpoint api/v2/devices and which have a notforreadonlyuser flag are now masked with asterics. This change also affects the api/v2/experimental/schemas endpoint.
• We fixed an issue where an internal (500) server error occurred instead of a proper error message when you sent an empty group name with the request body to the endpoint api/v2/experimental/groups/{id}/device or api/v2/experimental/probes/{id}/device via POST request.

We fixed an issue for dialogues that disappeared partially behind the resize handler in the split view of the new UI. For example, when you have created a new device, you will receive a pop up dialogue success message object successfully created which could disappear partially behind the resize bars.

We have added the Channel Unit Configuration section to the device settings, where you can configure default units for the channel types Bandwidth, Memory, Disk and File via dropdown menu. You can also use the Inherit From toggle for those settings.

• We fixed an issue for the Device Settings page on mobile view where long texts where not displayed within the frame of the page but going out of bounds.
• We improved the display of pages where no data was found in the new UI for mobile view. For example, if you previously wanted to open a device or sensor list for a group without objects, the page would simply display a blank page with no content. You will now receive a proper error page with a message in this case that displays no matching results.

You are now able to delete multiple objects in the Sensor list or Device list via bulk edit selection. You will see a confirmation dialogue that asks you if you want to cancel or confirm the deletion of the selected objects. You will receive an according error message if you do not have the necessary rights to delete certain objects.

We fixed an issue where you could not scroll down in order to see the full message when the sensor reported a down or warning message with a longer text.

• We fixed a reflected Cross-Site Scripting (XSS) vulnerability in the tag parameter. An attacker could inject and execute arbitrary JavaScript code in the user's browser context. To perform a reflective XSS attack, an attacker has to induce the victim to issue a malicious request, for example, by providing a prepared link. This vulnerability can be tracked under CVE-2025-67833, with severity 8.1 - High (CVSS v3.1).
• We fixed a reflected Cross-Site Scripting (XSS) vulnerability in the filter parameter. An attacker could inject and execute arbitrary JavaScript code in the user's browser context. To perform a reflective XSS attack, an attacker has to induce the victim to issue a malicious request, for example, by providing a prepared link. This vulnerability can be tracked under CVE-2025-67834, with severity 8.1 - High (CVSS v.3.1).

For further information please also see our Knowledge Base article: Vulnerabilities in PRTG prior v25.4.114.1032

Thanks to USD HeroLabs who made us aware of those vulnerabilities.

We fixed a Denial-of-Service (DoS) vulnerability in the Notification Contacts functionality. An authenticated attacker could cause service disruption. This vulnerability can be tracked under CVE-2025-67835, with severity 3.5 - Low (CVSS v3.1).

For further information please also see our Knowledge Base article: Vulnerabilities in PRTG prior v25.4.114.1032

Thanks to USD HeroLabs who made us aware of the vulnerability.

Various other minor fixes and improvements, updated user manual.

We updated the German and Spanish language files.

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

We fixed an issue for the VMware Datastore (SOAP) sensor that created an extra non-functioning channel when you have set your PRTG to a different language than English, for example German or Spanish. This channel did not deliver any values and therefore generated an error status, while the actual Free Space channel continued to function. Please note that existing VMware Datastore (SOAP) sensors will still show this extra channel when you update to this PRTG version, the fix applies when you create this sensor type new.

We fixed an issue for the Windows Updates Status (PowerShell) sensor which has been reporting the following error since the last Windows update from October 14th, 2025: Update history does not contain any entries. Please enable the sensor debug options and contact support for further help. The issue happened when your target system was Windows Server 2025 or Windows 11 updated to latest Windows patches.

To update to this Stable 25.4.114.1032 and subsequent PRTG versions, you must first install the following PRTG version: 25.4.112.1189 Stable. PRTG 25.4.112.1189 serves as an intermediate version when you want to update from older PRTG versions to this and subsequent versions. This step is necessary because we had to migrate our codesigning certificates to a new Cloud endpoint.

This release contains a new code signing certificate and a corresponding intermediate version which will cause the auto-update process to run two times, please be informed that this could lead to longer update times and multiple reboots.

Important: If you update your PRTG manually, please note that you need to update to the intermediate version 25.4.112.1189 first before you are able to update to the released PRTG version 25.4.114.1032.

If you are running a canary channel, the auto-update process may run into problems. You need to either switch to the stable channel for one full update cycle or install the newest update by hand since there is no intermediate version for this version channel available, we are sorry for the inconvenience.

In certain cases, the PRTG core server does not start anymore after updating to PRTG 25.4.114 and the log file core.log contains the message:
 

• Signature of \Program Files(x86)\PRTG Network Monitor\32 bit\PRTG Server.exe is not valid or
• Signature of \Program Files (x86)\PRTG Network Monitor\64 bit\PRTG Server.exe is not valid

The issue mainly affects PRTG installations that are offline or have limited access to the internet and happens if the code signing signature fails due to a missing trust chain in the trusted root certificates of the Windows certificate store.

You can resolve the issue by adding the trusted root certificate for timestamp signature. For more information, see the Knowledge Base article After updating to PRTG 25.4.114, the PRTG core server does not start anymore.

We currently face an issue in the Veeam Backup Job Status and Veeam Backup Job Status Advanced sensors that do not yet support Veeam 13 for Veeam Backup Enterprise Manager and Backup Server. If you update your systems to this new Veeam version, the sensors will report an error with the message that the JSONPath is incorrect. When you create new sensors of that type, you will receive the following error message: The meta-analysis returned no valid results. Check if the sensor is compatible with the equipment. (code: PE069) We are currently working on a fix for this issue.

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

Stable 25.4.114.1032

• sha256_exe 7AE43FB27631364502DB8C5E635329E15B6542F9FE930B4A955C8A5B2CFA9BBF
• sha256_zip C339DAF3FA37BCDD601CE8F5B620A926C7B2D3F313F810690F2DFC03DAAFFE59

• You are now able to create the following sensor types with the new endpoint /experimental/devices/{id}/sensor via POST request: EXE/Script sensor. The new endpoint is listed under the Sensors section in Swagger UI and gives you information about supported sensors.
• The schemas endpoint /api/v2/schemas now returns the lookupkey value correctly, for example lookupkey = intervalid or usergroupid.
• We removed the field kind_variant from all endpoints. This field returned, for example, the value device when you executed a GET request on the api/v2/devices endpoint.
• We changed the Schemas endpoint experimental/schemas/{kind} in PRTG API v2 so that it is replaced with the following endpoints: experimental/schemas/{parent}/post (for creating objects), experimental/schemas/{id}/patch (for updating objects) and experimental/schemas/{id}/get (for reading objects). You can use the include parameter as a filter for these endpoints in your requests.
• The Web.log will now create log entries when you execute an API request in PRTG API v2 Swagger UI with an invalid or deleted API key. Requests via API v2 with invalid API keys were not logged before.

We fixed an issue for the logout button which was not displayed within the mobile view window and where you had to scroll down to the end of the page in order to logout.

With this PRTG version we introduce the new SNMP Linux Disk Free v2 sensor which is the successor to the SNMP Linux Disk Free sensor. This sensor monitors the free space on disks of a Linux/Unix system via SNMP. The SNMP Linux Disk Free v2 sensor is also compatible with the Multi-Platform Probe.

We updated our HTTP Client Axios for Browser and node.js to version 1.11.0 which fixes a critical vulnerability regarding the used form-data version.

We hardened PRTG by improving input sanitization.

We updated the sensor schema for certain sensor types that is used for setting channel limits. Affected sensor types are the Script v2, SSH Script v2 (BETA) and REST JSON Data sensor (BETA) sensor. The schema was updated to version 3, which ensures support for setting channel limits.

Various other minor fixes and improvements, updated user manual.

We updated the German and Spanish language files.

The Activation Token that shows the identifier of your license is now also displayed for PRTG offline license activations. You will see the Activation Token below your System ID on the License Status page when you select Manual (offline activation) for your license.

We fixed an issue that could occur during PRTG getting online activation data for a license and if PRTG encounters an exception at the same time. For example, in case of an 500 server error, PRTG would stop completely during activation resulting in an unavailable web interface. PRTG will now catch the exception and list it in the CoreActivation.Log. Furthermore, the PRTG web interface will be available and will direct you to the landing page /activation.htm in these cases.

We fixed an issue that occurred on PRTG stable version 25.3.110.1313 for Paessler PRTG Hosted Monitor where invited users were not able to log in to the respective instance. The error message displayed was You are not authorized to access this PRTG instance.

We fixed an issue regarding Overload Protection, where PRTG would display the message Warning! Overload protection is active! Click here to learn more even in cases when no Overload Protection was active due to how the value addition is handled for failed login attempts. For more information about Overload Protection and why it is used in PRTG, please see our Knowledge Base article: What is overload protection?

We fixed an issue for the REST Custom v2 sensor where the JSONPath setting for session based authentication was not correctly processed when you selected JSON format as Login Result Type. The login would fail with a 200 HTTP response code, instead 201 (created) should have been returned.

We are currently experiencing an issue with the Windows Updates Status (PowerShell) sensor, which has been reporting the following error since the last Windows update from October 14th, 2025: Update history does not contain any entries. Please enable the sensor debug options and contact support for further help. The issue happens when your target system is Windows Server 2025 or Windows 11 updated to latest Windows patches. We are currently investigating this issue with the highest priority.

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

Stable 25.4.112.1189

• sha256_exe A1C764BAA3D02040E35B5E938AE85B31DC25EDB277FF635A3BBD29E1724E0931
 
• sha256_zip 35FAA3B7B3F773C2D35150A7C59DB79BD05D140AD08E51828572714A429EDE2D

• We fixed an issue where it was possible to move the ProbeDevice via endpoint /experimental/devices/{id}/move to another Group/Device/Probe. The issue occurred also for the actions clone and delete via APIv2. The ProbeDevice is fixed in PRTG and cannot be deleted, cloned or moved anymore via APIv2.
• The IP address is now logged in the core logfiles, furthermore the Audit Log, in case of a failed login via ApiToken-Provider. The issue occurred in the PRTG application server where the IP address was not set in previous PRTG versions and thus could not be logged in those cases.
• You are now able to create the following sensor types with the new endpoint /experimental/devices/{id}/sensor via POST request: AWS Cost sensor, Cloud Ping sensor. The new endpoint is listed under the Sensors section in Swagger UI and gives you information about supported sensors. All setting sections, including lookups, are supported for this sensor type.
• We have added the field primary that is included in the response code when you execute a GET request on the endpoint /experimental/channels. When you filter for the primary field (true or false) you will receive a list of primary or non-primary channels accordingly.
• We fixed an issue for the experimental endpoint /experimental/devices that returned the status PAUSED_UNTIL for paused objects by user when you executed a GET request. This status did not match our Schema and will now return PAUSED_BY_USER_UNTIL for objects that were paused by user until a certain date or time.
• We added two experimental endpoints /experimental/usergroups/{id} and /experimental/usergroups to PRTG API v2 that return a list of created user groups or by ID when you set the include parameter first upon a GET request.
• We improved the experimental endpoint /experimental/devices/{id}/sensor to accept certain sensor types via POST request when those sensor types have a version number in their name. The endpoint will now accept those sensor types with or without the version number. This change affects the AWS Cost sensor and Ping v2 sensor for now. You will also find an additional note under this endpoint listing the supported sensors.
• We improved the handling for endpoints in PRTG API v2 that are not available for Paessler PRTG Hosted Monitor instances. For the endpoint /users/reset-password, for example, we now display a note that the endpoint is not available on Paessler PRTG Hosted Monitor. When you execute a POST request on this endpoint for password reset, you will receive a HTTP 501 error response that this method was not implemented yet.
• We updated our Open API Specification available on API v2 Overview? regarding the endpoints in the sections Experimental and Deprecated.

• We fixed an issue for the PRTG application server that ignored parsing errors of the appserver.config.yaml and started with a default configuration. The PRTG application server will no longer start in this case and exit immediately, leaving a panic logfile with a message that explains the issue. This happened, for example, if lines for accesskey and clientuuid existed in the appserver.config.yaml.
• We fixed an issue for the PRTG application server that occurred when you updated to PRTG version 25.2.108.1358. The PRTG application server would crash sporadically in certain cases and create a panic logfile with the message: panic: runtime error: invalid memory address or nil pointer dereference.

We added the option to select a sensor as dependency in the settings Schedules, Dependencies and Maintenance Windows. For the setting Dependency Type you will now see the radio button option Select a sensor. When you click on this option, a sensor selection UI appears, where you can choose from available sensor types.

You are now able to set a Scanning Interval in the device settings via drop down menu. Additionally you have the option to set a sensor Status with the setting If a Sensor Scanning Fails.

We added a selector for device templates that you can now open in the new UI of PRTG. The Confirm button is disabled when you do not make changes to the selection. When you change the selection for device templates, you are not able to close the dialogue but have to click Confirm instead.

We fixed an issue for sensor graphs that were not correctly displayed in the new UI. For example, when you opened the Graphs tab of a sensor and used the Expand option and added one or two more channels, you would see only one channel graph in this case.

We fixed an issue where the vertical scrollbar on the Sensor List tab under Monitoring only appeared at the bottom of the page when you scrolled down. The vertical scrollbar is now visible on the whole page for the Sensor List if scrolling is necessary.

We fixed an issue that occurred when you logged out of the new UI on mobile view. Upon logout, an unknown error would be displayed.

We fixed an issue on the sensor overview page that occurred sporadically. The issue could happen when you navigated to the sensor overview page and would show an error popup window on the channel gauge view.

This version comes with an improvement for Application Health Status where you can configure ITOps Board to send a notification when warnings or errors are raised for an integration or for the Vantage DX application. By default, notifications about application health are disabled. You must be an administrator to enable these notifications.

If you use a remote agent, you must update it in this release. This procedure must be performed by an administrator.

Additionally, the following application issues were fixed in this release of ITOps Board:

• Upgrades failed if the user performing the upgrade had insufficient SQL server permissions. The installer now uses the Application Pool identity for the database upgrade.
• The times of outages recorded in the SLA report are not displayed consistently for all regional settings. For some regional settings, the SLA report displays the times of outages but does not indicate am or pm.
• If a child board is pinned to two or more parent boards, users in non-administrator roles are unable to view the child boards.
• The application displays an SQL timeout error and becomes unresponsive.
• SLA data is not calculated for business services and shows an error state.
• Alerts related to a child board are not visible on the parent board.

A new version of the multi-platform probe is now available! With this release the multi-platform probe now supports the SNMP Linux Block Device I/O and REST JSON Data sensor. For more information about the supported sensors please see the manual, Multi-Platform Probe for PRTG

For detailed release notes about this release, see our Knowledge Base article: What are the release notes for the Multi-Platform Probe?.

The REST Custom v2 sensor has left its BETA status and is now fully supported with this PRTG release. We introduced the REST Custom v2 sensor as experimental sensor with PRTG version 21.2.68.1492. The REST Custom v2 sensor queries a JSON or XML REST API endpoint and maps the according result to sensor values.

During sensor creation, the REST Custom v2 sensor will now have a pre-filled value in the field Request URL for the section Specific Sensor Settings. The field displays https://%host/ to make it easier to identify the supported placeholder. The Request URL field was empty before in previous PRTG versions.

With this version we introduce the new SNMP Linux Block Device I/O sensor, which is the successor to the SNMP Linux Physical Disk sensor. This sensors monitors the input/output (I/O) on disks of a Linux/Unix system via SNMP.

For more information about this sensor, for example, in case you change the SNMP version, please have a look at our Knowledge Base article: Why did my SNMP Linux Block Device I/O sensors stop working after I changed my SNMP version??

The SSH Disk Free v2 sensor has left its BETA state with this PRTG version and is now fully supported. This sensor monitors the available disk space of a Linux/Unix system using Secure Shell (SSH). We released this sensor type as experimental (BETA) sensor with PRTG version 25.1.104.1946.

We improved the session based authentication method for REST API based sensors to accept more success response codes in the range of 200-299. The Credentials for REST API only accepted the HTTP response code 200 OK for session-based authentication in previous PRTG versions.

To offer more details and information on a sensor, we added the following columns to the sensorlist.htm: Premeta (if the sensor requires a pre-meta scan), MinInterval and Momo (if it is a rewritten sensor type or not).

Various other minor fixes and improvements, updated user manual.

We updated the German, Spanish and Japanese language files.

We updated the language files in German, French, Portuguese, Russian, Chinese, Japanese and Dutch for certain selected sensor types.

We fixed an issue that occurred on addsensor4.htm where large metascan entries during sensor creation could lead to an ajax timeout (PE:PE1113) in certain cases due to our update to Delphi 12.2 which also processes this page. This issue occurred, for example, if you tried to add SNMP Traffic sensors to a device with a large number of interfaces.

We fixed an issue where a device and sensor with status paused by dependency could not be resumed. The issue occurred, for example, if a sensor was put into simulated error status and this sensor was not set as Master sensor for parent on the according device. In this case, you could not resume the sensor afterwards as it also went into the state paused by dependency. The sensor will now remain in the error status to be able to be resumed again.

We fixed an issue where license activation for PRTG did not work in certain cases when the license activation file contained certain unicode/UTF characters that could not be decrypted. For example, when the license name included such a special character like Á or a long hyphen, you could observe the following error in the CoreActivationLog: No mapping for the Unicode character exists in the target multi-byte code page. The License status would also return Activation message processing has failed. in these cases.

We fixed an issue for SMTP notification delivery when you have set your Notification Delivery settings to Use direct delivery with the built-in email server (default). This issue occurred with updating to PRTG version 25.2.106.1114 where email notifications were sent several times instead of only once and was happening only for the PRTG internal SMTP relay server.

• We fixed an issue for email notifications that were sent immediately after a sensor went from paused state into a resumed state and therefore got the status unknown first before collecting data. The issue occurred when you have set a State trigger to this sensor that applies when the sensor stays in an unknown status for a certain time period. PRTG will now recognize the transition from paused state (by user, by dependency, by schedule, by license and until) and will only trigger the notification when the configured trigger applies.
• You will now receive test notifications properly for MQTT messages within a notification template when you click on the button send test notification. In previous PRTG versions, PRTG would send the test notification with the prefix TEST, what therefore changed the topic you have subscribed to and thus you did not receive the according test notification. We have now added the wording TEST to the body of the notification, so that the topic will not change in this case.

We fixed an issue for reports that could not process umlauts correctly when you ran a report that included data files within the setting File Format and Delivery. For example, sensors with channel names that include umlauts were not displayed correctly in the xml file after generating the report with those sensors included. The issue occurred with PRTG version 25.1.104.1961.

We fixed an issue for the NetApp SnapMirror v2 sensor that reported the value 0 for the channel Lag in certain cases. The issue occured only for the NetApp SnapMirror v2 sensors. In course of this, we changed the default name of NetApp SnapMirror v2 sensors to show the destination path instead of the source path in the sensor name to ensure that the NetApp SnapMirror v2 sensor uses the same instance name as its predecessor NetApp SnapMirror v1.

The Ping v2 sensor will now keep the dependency when you create a device template with an according Ping v2 sensor that is set as Master sensor for parent for the device. Previously, when you run an Auto-discovery with specific device templates before, the Ping v2 sensor would be created afterwards, however, it was not set as Master sensor like in the original device.

• We fixed an issue for the REST Custom v2 sensor that ignored Custom HTTP Headers settings for the type Accept header. For example, if you defined an Accept header in the Custom HTTP Headers of the REST Custom v2 sensor, the header value would be overwritten in the previous PRTG version. The header is now transmitted correctly and you can see the value in the response of the Result of Sensor logfile.
• We fixed an issue for REST Custom v2 sensors that went into a down or warning state with the message Creation of rest_custom_v2_sensor failed: The setting "authentication_section.authentication_group.login_path" was not available when you updated to PRTG version 25.2.108.1358. A possible workaround for this issue was to pause and resume the sensors to make them run again.

We fixed an issue for SNMP sensors that reported a timeout -2003 error in certain cases when you updated to the previous PRTG version 25.2.106.1114. The issue occurred in cases when you had SNMP sensors configured with SNMP version v3.

We fixed an issue that occurred in certain cases when you replaced your SSH Remote Ping v1 sensors with the successor SSH Remote Ping v2 sensors. We deprecated the SSH Remote Ping v1 sensor with PRTG version 25.2.108.1358. In this case, the SSH Remote Ping v2 accidentially would use the SSH host as device instead of the remote target, what resulted in wrong values. You could also observe that the sensor did not display any packet loss which worked with the v1 sensor before.

We fixed an issue that occurred for certain SSH v2 sensors when you updated to PRTG version 25.2.106.1114. The issue happened only for v2 sensor types, that is why you have been able to observe it in these particular cases after the sensor migration for the SSH INodes Free v1 sensor. The sensor was not able to reconnect to the target device after a broken connection in some circumstances, which we improved now by changing the logic for reconnection.

We fixed an issue for the WMI Event Log sensor where the handling for overflow values did not work properly. For example, when the sensor received and displayed values and you restarted the PRTG probe service, you could observe a high peak in the values afterwards.

We fixed an issue for Sensors With Alarms where objects were not displayed in the column Probe Group Devices. This issue was also fixed for the new UI and occurred only when you used Firefox as web browser.

We fixed an issue in the PRTG Tickets tab that occurred in the Select a Group, Device or Sensor from the list section when you clicked on Add Ticket. The elements from the device tree would be overlapping in the search field in previous PRTG versions.

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

With this PRTG version we deprecate the Common SaaS sensor. You cannot add this sensor anew when you update to this PRTG version, however, existing sensor types continue to run. This sensor will not have a successor v2 sensor. You will receive an according TO DO ticket from PRTG when you update to this version.

With this PRTG version we discontinue the SSH INodes Free v1 sensor. We announced the deprecation of the SSH INodes Free v1 sensor with PRTG version 25.2.106.1114 where also existing SSH INodes Free sensors were migrated to their successor v2 sensors. Please note that existing SSH INodes Free v1 sensors will stop working when you update to this PRTG versions, however, this does not apply for migrated SSH INodes Free sensors. It is not possible to create an SSH INodes Free v1 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?

With this PRTG version, the following sensor types are migrated to their successor v2 sensors: SSH Meminfo, SSH Load Average and SSH Remote Ping sensor. PRTG will sent an according TO DO ticket with all relevant information. We announced the deprecation of SSH Meminfo, SSH Load Average and SSH Remote Ping sensor with PRTG version 25.2.108.1358.

With this PRTG version we discontinue the Python Script Advanced sensor. We announced the deprecation of this sensor type with PRTG version 25.1.104.1946. Running sensors of this type will stop working and report an error message about the disontinuation and the Python installation will be removed when you update to this PRTG version. To ensure further monitoring, please use the successor Script v2 sensor instead and make sure to adjust your custom scripts in advance.

For more information please see our Knowledge Base article: What do deprecation and discontinuation in the context of sensors mean?

Read here for differences and more information about the two sensors: Why should I use the Script v2 sensor?

We also provide information on how to migrate your scripts with this Knowledge Base article: How can I make my Python scripts work with the Script v2 sensor?

With this PRTG version we display an Activation Token on the License Information page. This token shows the identifier of your activated license. The Activation Token is displayed for Paessler PRTG Enterprise and Subscription licenses and valid also for offline license activations.

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

Stable 25.3.110.1313

• sha256_exe 16649C98C3EBF43D982E4798448661140704D6209751298AEA4B26A4A3C9D674
 
• sha256_zip 82BF773F808FFEE8ED9AB05F1520E296C2499A1D3430F4170CE7ED64472B4913

You can try out the experimental REST JSON Data sensor (BETA) that we introduce with this PRTG version. This sensor queries an HTTP endpoint which returns JSON data in a well defined format. The format is the same as for the Script v2 sensor. Depending also on the JSON response, the sensor will create the channels Status and HTTP Status, amongst others. This sensor is also compatible with the Multi-Platform Probe.

• We improved our internal naming conventions to be more consistent in the format. In course of this, we renamed the property _inheritanceSource to to _inheritancesource.
• We implemented a new endpoint /experimental/devices/templates that returns a list of available device templates upon GET request.
• You are now able to create a Ping sensor with the new endpoint /experimental/devices/{id}/sensor via POST request. The new endpoint is listed under the Sensors section in Swagger UI and gives you information about supported sensors: This endpoint does not yet support all sensor types. Currently only the following sensors are supported: * Ping. The body of the POST request contains the settings of a ping sensor as defined in the schema, for example, required fields and settings sections.
• We fixed an issue where a remote probe returned the status CONNECTED in the PRTG API v2 under yourserver:1615/api/v2/probes/ID although it was not approved yet. You will now receive the correct status for the remote probe PENDING_APPROVAL in this case.
• You can now send a GET request on the endpoints /experimental/objects or experimental/groups/{0} with the include parameter and value all. Previously, the inheritanceSource would return unknown_reference_object_type for the type field. You will now receive correctly REFERENCED_ROOT.

• We improved the supported number of ciphers used in the TSL configuration for Default security (TLS 1.3, TLS 1.2) (recommended) that you can edit in the PRTG Web Server settings for Connection Security. The setting for Weakened security will still support older TLS versions and all current cipher suites used in the PRTG application server.
• We fixed an issue that occurred in previous PRTG Preview version 25.3.109.1353 where an HSTS( Strict-Transport-Security) header was not sent correctly by the application server. The PRTG application server will now no longer send an example HSTS header during installation. Please use appserver.config.yml for configuration of an own HSTS header.
• We fixed an issue for the PRTG application server that got stuck in certain cases during shutdown process and where it has hung up during the step unsubscribing from core notifications. As a result, also core and web server processes were not able to shutdown. A possible workaround was to manually stop the process.

We fixed an issue that occurred in certain cases when you have added a PRTG Subscription license and when displaying PRTG in the new UI was not possible. PRTG Subscription license types were enabled in the PRTG core, however, in certain cases the PRTG application server did not recognize them as valid. When you clicked on Open new UI button on the login page, PRTG would show An unknown error occurred in these cases.

We updated our typography throughout the New UI to match the design system.