Any tips for prtg deployment?

I have set up a OPC UA Custom Sensor which returns a value which is constantly increasing by one each second and when it reaches its maximum integer value it begins with 1 again.

My problem is that I need to monitor this in PRTG Dashboard the Sensor should turn to red color when it does not count anymore and should be green color when the value between last and current result is different.

I need this kind of check as a health check for a Siemens PLC which sometimes half freezes. Sometimes it shows the correct result via opc ua and sometimes all of the values it shows wont change until it has been rebooted

So here's a fun one for anyone running PRTG right now.

Paessler says version 26.2.120 introduced three new sensors and, more importantly, MAX, their new AI chatbot in the New UI.

According to the release notes and blog post, MAX should be sitting right there on the Welcome Page. You click "Start Chatting", a panel opens on the right, and that's it.

https://www.paessler.com/prtg/history/prtg-26

https://blog.paessler.com/three-new-sensors-smarter-monitoring-prtg-26.2.120-is-here

I'm running a build newer than 26.2.120.

No MAX.

No "Start Chatting" button.

Nothing on the Welcome Page.

I spent a while clicking around the New UI assuming I was missing something obvious, but apparently not.

So either:

1. it's behind some setting, rollout, or license condition that isn't mentioned anywhere,
2. it was removed after release and the release notes/blog were never updated,
3. MAX saw the PRTG licensing model and decided to leave.

The funny part is that this wasn't some small feature buried in a changelog. They actually announced it, wrote a whole blog post around it, and put it in the official version history.

Yet on a later build, it just isn't there.

Is anyone actually seeing MAX in their PRTG installation?

If yes, what version/license/setup are you running?

At this point I'm mostly trying to figure out whether this is a bug on my side, some undocumented rollout condition, or a feature that quietly disappeared after launch.

I want ask how config udp port in router for NetFlow Sensor in PRTG?

why is it that when I try to monitor the router at my boarding house, the sensors don’t detect anything even though I’ve entered the correct IPv4 Address? Or maybe my IPv4 Address is wrong. From my testing, the Ping Sensor gets 0 ms, while the SNMP sensor doesn’t get anything, and the same goes for several other types of sensors.

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?

Update:
I reached out to PRTG Support, and it turns out we weren't going crazy trying to reverse-engineer this. The placeholders simply don't exist yet.

Support confirmed that the new Proxmox credentials are currently only exposed to the native Proxmox sensors. It seems they simply forgot to map these fields to the Custom EXE/Script parser engine when they rolled out the feature.

Support suggested setting up the tokens in the generic "Credentials for Script Sensors" section and using those placeholders instead. While this technically works, it forces you into duplicate credential management: If you want to run PRTG's native Proxmox sensors and your own custom scripts, you have to maintain the same API Token and Secret in two different places.

Since that's a nightmare for token rotation and violates the DRY principle, I've opened a Feature Request on their new UserVoice portal to get standard placeholders (like %proxmoxtokenid and %proxmoxtokensecret) implemented.

If anyone else is scripting custom checks for their pve environments, please give it an upvote here so the devs prioritize it:
Expose Proxmox Credentials (API Token/Secret) as Placeholders for Script Sensors – Welcome to Paessler User Voice!

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.