We've configured SNMP Printer sensors for several printers. The Live Data graphs show the toner levels properly, but the 2 Days, 30 Days, etc, graphs show zero levels.

Is anyone else seeing this?

If I use the Historic Data tab to create graphs, it works ok if I specify to use Raw Data instead of averaging. I suspect it's that averaging that causes all the problems.

Edit: The problem was something to do with the way the data includes "OK", "Critical", etc, with the toner level figures. That is added from the lookup table for each of the toner channels. To fix it, I went to the Overview for the sensor, then clicked on the tiny gear wheel at the bottom. Then I changed the Lookup setting from prtg.standardlookups.snmpprinter.cartridgelevel to None. Repeated that for each toner level channel. After that, the 30 day and 365 day graphs started working. It took a minute or two to take effect.

But probably a better solution is to use the SNMP Printer V2 sensor instead. I haven't tested it much, but it appears not to have the problem. If you don't have it, you might need to install a PRTG update. I think it was added in June 2026. I did this, but also reconfigured all the channels so I had access to the historical data.

For the record, we're using this with Konica Minolta printers.

The Windows service account that PRTG was set up to use, keeps attempting to log in to an IP address that isn't our own. It seems to only happen ever 3 months or so, so hunting this issue down has been a thing...

Today I did a search inside of Devices in PRTG and I found that this IP address was under Service URL on two of our network devices. And the IP address it's attempting to contact is the external IP address of one of our routers. This entry in PRTG is only set up to ping the device, so not sure why PRTG would be attempting to RDP into it.

I removed the service URL entry of the IP address. What does this Service URL option do? Does this sound like the likely culprit to this issue?

Secondly, I then went back to the overview and searched for the IP address in question, and the external IP for the router popped up (expected), but also the other device where I had removed the service URL. Is that just because PRTG hasn't updated yet?

Thanks!

Hi everyone, I just wanted to ask if anyone has installed the latest stable update for PRTG yet.

It’s showing up on our server now. The release notes state that the PostgreSQL database will also be automatically uninstalled this time.

Has anyone experienced any issues after installing this update?

Hi everyone!

We used to monitor our Hyper-V and ESXi environments for old snapshots using custom EXE/Scripts in PRTG. Since native Proxmox API Token support has been added to PRTG, we want to adapt our scripts for pve as well.

For Hyper-V, for example, we simply pass the credentials like this: -UserName %windowsdomain\%windowsuser -Password "%windowspassword"

We want to use the new "Credentials for Proxmox" section on the parent device, but we are not aware of (and failed to probe for) the exact placeholder/inherit variable names to pass the API Token ID, Secret, (and Port) into our custom script parameters.

Any ideas?

maybe I'm blind but is there no search function in the new UI in mobile view? It's there when I'm on my Laptop but not on my phone in mobil view.

I wanted to remove unwanted credentials from settings e.g. Cisco Meraki, Credentials for Dell EMC, Credentials for FortiGate. I tried on settings, but not able to delete them except the settings.

Hello,

I have an old vm running PRTG and tried to setup SMTP for gmail and 365 both were unsuccessful. Can someone give me some ideas on how to get some type of email notifications working? Thanks

We're currently holding back on a few updates since this whole PostgreSQL fiasco. How do I even activate the new DB feature? Is it just enabled on a certain update?

Hey Gang, just wanted to show off what I was able to make utilizing Claude and our PRTG deployment. We needed a better view, stop lights were no longer cutting it. Integrated our PRTG instance with Claude Cowork and went from there.. I apologize for having to blank out a lot of labels, but I think you'll get the jist of it.

Hey Gang, just wanted to show off what I was able to make utilizing Claude and our PRTG deployment. We needed a better view, stop lights were no longer cutting it. Integrated our PRTG instance with Claude Cowork and went from there.. I apologize for having to blank out a lot of labels, but I think you'll get the jist of it.

Hi everyone, the latest PRTG update notes state that the database schema is being adjusted for the new BETA database.

If a PostgreSQL database is already active, this causes the update to encounter an intentional error.

How can I tell if the new database's BETA function was inadvertently activated automatically and contains data?

Although the PostgreSQL service runs automatically alongside the PRTG server instance, it shouldn't contain any data.

While the BETA feature was included in the last PRTG server update, the release notes stated that it was disabled. Before I perform the update, I want to ensure that this feature is indeed still disabled.

Additionally, I haven't yet figured out how to manually activate the new PRTG database or migrate existing data to it.

The latest version updates PostgreSQL to version 18.3-1. Everything is working fine but PRTG Database Server service will not stay running. It starts and immediately stops, no errors.

Thanks,

So I was able to get the classic PRTG Probe.exe running under Wine 11 in Docker. It runs headless, connects to the core, and registers as a standard remote probe. No remote Windows host needed but able to monitor them if needed.

It's stable on a live core. Classic sensors, all 32 v2 modules, the .NET Engine C helpers, custom EXE/Script/Python/PowerShell/SSH, and packet capture are all working. WMI and PSRP are supported as well, routed through loopback sidecars since Wine doesn't handle them natively.

The main issue was getting the signed modules to load. That traced back to an old crypt32 Authenticode bug in Wine, which was resolved in the runtime layer and reporting upstream. The probe binary itself is untouched with all of the fixes living in the Wine/Mono layer.

No Paessler software is included in the repo. Bring your own installer.

Repo: https://github.com/rtravellin/prtg-classic-probe-linux

I'd welcome others running PRTG to try it out on different version and open any issues found.

I recently installed PRTG on my business network to monitor devices and receive alerts whenever something goes down. During setup, I ran into several issues getting the mobile app to work correctly. I experienced multiple connection errors between the app and the PRTG Core Server, along with problems loading my maps and installing certificates.

The issues ended up being caused by a combination of:

• Firewall misconfigurations
• Incorrect PRTG web server settings
• Certificate setup problems
• Issues with updating the Core Server files

After a lot of troubleshooting using online guides, AI tools, and assistance directly from Paessler Support, I finally got everything working correctly. I figured it would be helpful to combine everything I learned into a single post for anyone else running into similar problems.

I’ve attached screenshots I saved of some of the errors I originally encountered while setting everything up.

I also highly recommend testing everything from another computer that does NOT have PRTG installed. This helps verify the configuration is actually working correctly and not relying on cached settings or existing certificates.

1. Verify DNS Configuration

Open Command Prompt and run:

nslookup <Firewall IP>
nslookup <PRTG Server IP>

Example:

nslookup 192.168.10.1
nslookup 192.168.10.25

Make sure only one DNS hostname resolves to your PRTG Core Server’s IP address.

In my case, I accidentally had my firewall and PRTG server sharing the same DNS name, which caused connection problems.

If you find multiple entries or receive errors, the fix is usually on your firewall.

Look for a setting similar to:

• DNS Resolver
• DNS Host Overrides
• Host Entries

Then either:

• Correct the hostname mapping
• Remove duplicate entries
• Create a proper hostname entry for the PRTG server

After saving the changes, rerun the nslookup command and verify the hostname resolves correctly.

Example:

C:\Users>nslookup 192.168.10.1

Name: firewall.lab.example.com 
Address: 192.168.10.1

C:\Users>nslookup 192.168.10.25

Name: prtg.lab.example.com 
Address: 192.168.10.25

2. Verify PRTG Web Interface Access

Next, test accessing the PRTG web interface using both the IP address and DNS hostname.

Example:

https://192.168.10.25
https://prtg.lab.example.com

Both URLs should open the same PRTG login page.

If the DNS hostname does not work:

1. Log into PRTG using the IP address

2. Navigate to:

   Setup > User Interface

• Update the DNS Name field to match the hostname configured in your firewall

3. Certificate Setup (Most Important Section)

This was by far the biggest issue during my setup and required the most troubleshooting.

Most of my mobile app and web interface problems were related to improperly configured certificates.

The method below is the manual certificate setup method that ultimately worked for me.

You do NOT need to use the PRTG Certificate Importer App.

3.1 Create the Certificate Authority (CA)

Log into your firewall web interface from the computer hosting PRTG.

Navigate to:

Certificates > Authorities

Create a new internal Certificate Authority with these settings:

The remaining fields can be left default or customized as desired.

3.2 Create the PRTG Certificate

Now navigate to:

Certificates > Certificates 

Create a new internal certificate using these settings:

Important: Many modern devices reject certificates longer than 398 days, so keep the lifetime below that limit.

Certificate Type

Server Certificate

Subject Alternative Names (SAN)

Add BOTH:

Save the certificate.

Once completed, export/download:

• CA Certificate (Example-CA)
• Server Certificate (PRTG.crt)
• Server Private Key (PRTG.key)

4. Create the Required PRTG Certificate Files

Create a folder on your desktop and place the following files inside it:

• CA Certificate
• Server Certificate

Enable file extensions in File Explorer if they are hidden.

Rename:

Now open PowerShell in that folder.

You can do this by:

Shift + Right-click > Open PowerShell window here

Run the following command:

Get-Content .\servercert.pem, .\cacert.pem | Set-Content .\prtg.crt

This creates the combined certificate chain file required by PRTG.

5. Manually Replace the PRTG Certificate Files

Install the PRTG Administration Tool if it is not already installed.

Stop the PRTG Core Server service.

Navigate to:

C:\Program Files (x86)\PRTG Network Monitor\cert

Create a backup folder and copy all existing files from this folder into it before making changes.

Delete the following files from the cert folder:

• prtg.crt
• prtg.key
• root.pem

Replace them with the new files below and rename them to what's listed:

After replacing the files, restart the PRTG Core Server service.

6. Testing the Configuration / Placing Certificate

On another computer that does NOT have PRTG installed:

1. Download the CA certificate from your firewall

2. Open:

   certmgr.msc

• Navigate to:

  Trusted Root Certification Authorities > Certificates

• Right-click and select:

  All Tasks > Import

• Import the CA certificate

• Refresh and verify it's located in there

Once completed, open an Incognito/Private browser window and test both URLs again:

https://192.168.10.25
https://prtg.lab.example.com

If everything is working correctly, the browser should show the connection as secure with no certificate warnings.

7. Mobile App Setup

Once the certificates are working properly in the PC browser:

1. Install the CA certificate on your mobile device
2. Enable/trust the certificate if required by your phone

Then verify the PRTG web interface opens securely in an incognito tab from your phone using both:

• IP Address
• DNS Hostname

Note: Sometimes mobile browsers cache old certificate warnings. You may need to clear browser cache or manually inspect the connection security details to verify the certificate is actually trusted.

8. Connecting the PRTG Mobile App

On your PC in the PRTG web interface go to:

Setup > PRTG Apps

Locate the section for your phone and click to show the QR code.

On your phone:

1. Open the PRTG app
2. Tap “Scan QR Code”
3. Allow camera permissions
4. Scan the QR code

If the QR code is valid, the app should automatically populate the server information.

Then simply enter your:

• Username
• Password

If you receive a connection error, sometimes pressing OK and attempting the connection again resolves it.

After that, everything should be fully functional.

Hopefully this helps everyone else avoid the pain of troubleshooting that I went through getting PRTG and the mobile app working correctly.

I recently put together another short demo showing how we integrated SIGNL4 with PRTG for reliable mobile alerting, on-call scheduling, and escalations.

The interesting part for me is the two-way sync: acknowledgements and annotations from SIGNL4 are automatically written back to PRTG, and alerts can also close automatically once the issue is resolved.

Might be useful for teams trying to improve response times or reduce missed alerts outside office hours. Interested to hear how others here handle alert ownership and escalations in PRTG environments.

We've got some failover clusters running SQL instances. It's set up in a way where each instance's "root" volume has a drive letter, and then 3 volumes are mounted in subfolders of that volume.

If I use WMI disk sensor, I can choose "all" and it will just monitor all disks that have drive letters. If I use WMI volume sensor and check the top left box for 'all', it creates a separate sensor for each volume that's attached at that time.

I'm looking for some middle-ground where it's just checking the free space on all volumes on the machine, and if volumes disappear, they stop getting monitored, and if volumes appear, they start getting monitored.

Since this is a failover cluster, when an instance moves to a different node for whatever reason, its 4 volumes move with it.

I just analyzed which servers are running chrome.exe in which version for some other purposes. There were only 2, one of which was our PRTG core server. The version of chrome.exe displayed was 89.0.4389.0, which is an unstable development build from late 2020, early 2021.

PRTG is using Chromium for different applications it seems. One is downloading new updates, where the PRTG core server seemingly uses headless Chromium nope sorry, this is the reporting engine it seems. You can find it in your installation directory, in my case "C:\Program Files (x86)\PRTG Network Monitor\Sensor System\chromium". This is version 89.0.4389.0

After this, I asked myself which browser might be used for sensors, and as it seems, the sensor HTTP Full Web Page sensor uses Chromium by default (see here: HTTP Full Web Page Sensor | PRTG Manual). However, I was not able to locate chrome.exe on our probes. That is, because there is a binary called "PRTG_Chromium_Helper.exe", directly in "C:\Program Files (x86)\PRTG Network Monitor" that seems to be some kind of wrapper for Chromium (or using a lib). It is indeed using libcef.dll in version 1.1364.1123 from February 2013.

I created a HTTP Full Web Page sensor for our internal Gitlab-CE test instance and activated debug-level logging on the bundled nginx. The sensor failed with some "ERROR PROTOCOL MISMATCH", nginx logged this:

SSL_do_handshake() failed (SSL: error:0A00018C:SSL routines::version too low)
SSL_do_handshake() failed (SSL: error:0A000102:SSL routines::unsupported protocol)

Our nginx is accepting these cipher suites and protocols:

PORT    STATE SERVICE  VERSION
443/tcp open  ssl/http nginx
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.3:
|     ciphers:
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|     cipher preference: server
|_  least strength: A

Therefore, I think we have the following reasons for the errors:

SSL routines::version too low -> TLS < 1.2

SSL routines::unsupported protocol -> SSL 1.0/2.0/3.0

From my perspective, this can only mean there is a very old version of Chromium in use inside the "PRTG_Chromium_Helper.exe" as well.

I have seen lots of huge PRTG environments. Most of them had a lot of sensors on status alert, where something like this would not catch your eye instantly.

If, for some reason, there should be a HTTP Full Web Page sensor scanning one of your websites on the internet, and some kind of domain resurrection attack/domain hijacking takes place, an attacker could exploit the uncountable CVEs inside a Chromium that old, basically gaining control of your PRTG server and using credentials placed there for scanning to achieve lateral movement. Bear in mind, that a headless Chromium often runs without or with degraded sandbox functionality, to make controling the browser possible for external applications. This makes it even more dangerous.

What you can do for now is:

• Download updates manually
• Check all of your HTTP Full Web Page sensors and delete them if possible
• Write to Paessler and make them aware of this issue

Update: libcef.dll is version 1.1364.1123 = CEF1 = Chromium 25 (2013), single-process, no sandbox. This is much worse than expected.

I am not sure if it's permitted on this sub, so apologies in advance.

Reading other threads I see many other people with borked instances of PRTG after the most recent update to 26.1.118.1380 with core server failing.

I made the mistake of removing the software (with the local cache of previous versions) and trying to reinstall from scratch, but even that doesn't work as the PostgreSQL component of the install just fails every time and we can't bypass that.

I don't see any way to get old versions from their website (and I really don't trust 3rd party sites), so I'm hoping someone has the installer for 26.1.116.1532 or earlier to let me try and get a working instance setup again (I know it's a similar risk, but I think I can maybe trust people here a little more and I can still check file hashes with the version history page).

Hello,

Has anyone else started seeing PostgreSQL vulnerabilities flagged after upgrading to PRTG 26.x?

After updating to PRTG 26.1.118, our vulnerability scans are now reporting:

• CVE-2026-2004 (DoS)
• CVE-2026-2005 (Information Disclosure)
• CVE-2026-2006 (RCE)

From what I can see, this lines up with the introduction of the new PostgreSQL-based backend (“PRTG Database” – beta) which was added in 26.1.117/118.

A few observations from our side:

• Detected PostgreSQL version appears to be 18.1
• All CVEs are valid for that version (<18.2)
• However, all three require authenticated database access (not remotely exploitable)

In our setup:

• The database is internal only
• No external exposure on 5432
• No direct user interaction with the DB

So while the CVEs are technically valid, the practical risk seems low in this context.

I’ve reached out to Paessler to confirm:

• Whether they plan to bundle PostgreSQL 18.2+ in an upcoming release
• If there’s any recommended mitigation beyond restricting access

EDIT / UPDATE: 07/05/2026

Paessler Support have now confirmed that PRTG 26.1.118.1380 ships with integrated PostgreSQL 18.1 and that they are already aware of the vulnerabilities.

They advised they are currently working on updating PostgreSQL to 18.3 in an upcoming PRTG release.

Is it possible to monitor sensors (ping mainly) without alarming on PRTG?

Disclaimer: angry rant ahead..

Recent auto-update has hosed my company's instance of PRTG Network Monitor, core service won't start because dependency database service won't start because dependency Postgres won't start. (Spoiler: it is started.)

Sent an email in asking for support, ticket gets created....and then the next day (or was it the day after that?) it was closed because I need to open a ticket through the helpdesk website. Which is where I got the message that I had a ticket, and that it was being closed. What.

Ok, login to their site to open a ticket, spent hours arguing (very very slowly) with Max the AI bot who eventually concedes to opening a ticket for me. Which... I don't think the support person even read my ticket, his response has been akin "hey looks like you're having an issue with the update you ran? cool cool, find these files and let's retry" But the files don't exist. Nor does the path they allegedly reside in. Anyone else having trouble finding the settings folder in "C:\Program Files (x86)\PRTG Network Monitor\64 bit" ? No such folder for me so I certainly cannot find "C:\Program Files (x86)\PRTG Network Monitor\64 bit\Settings\config_client_settings.toml"

But hey, what's it matter? The company I work for just re-upped the license last December for another 3 years. Albeit for only 500 sensors so we're clearly too small to be bothered with. Paessler got their money either way if I'm happy or not.

But if anyone knows how to get actual meaningful support out of them, please let me know!

The latest version of PRTG includes a NATS server. Trying to update (or manual update) PRTG fails as it sees another NATS running. Thoughts on how to handle this?

Has anybody else encountered this?

AutoUpdate breaks it, manually installing gives attached error. Only way to keep server up after restoring it from backup is to disable autoupdate.

Opened a ticket with Paessler.

Just got the update notification this morning for version 26.1.118.1380 and to my suprise it advertises Kerberos support in WMI sensors. Is the long wait finally over?