What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags

View all Tags

How can I monitor the number of sensors in a specific group?



I would like to monitor the sensor count in a certain group in PRTG. How can I get the number of sensors in a group of devices? How do I include the sensor count in a sensor?

api custom-sensor exexml groups msp prtg sensor-count sensors xml-rest

Created on Dec 21, 2015 1:18:58 PM by  Gerald Schoch [Paessler Support]

Last change on Oct 15, 2020 8:05:15 AM by  Brandy Greger [Paessler Support]

5 Replies

Accepted Answer



This article applies as of PRTG 20

Monitoring the number of sensors in a specific group

In general, there are two ways to monitor the sensor count in a specific group. You can create an HTTP XML/REST Value sensor that uses the PRTG API to get the number of sensors in a specific group without sub-groups, or you can use a third-party sensor by PRTG Tools Family.

Monitoring the sensor count can be useful for managed services providers (MSP), for example.

Monitoring sensor count via the PRTG API

To monitor the number of sensors in a specific group without sub-groups, for example, sensors in the Paused or Unknown status, you can use the HTTP XML/REST Value sensor.

This approach retrieves a .json file via the PRTG API that contains the current number of sensor states and parses it. Define the sensor states you are interested in and add sensor limits depending on your needs.

Steps to take

  1. Manually add the HTTP XML/REST Value sensor to your PRTG installation.
  2. In the sensor settings, provide the following target URL: https://MY_PRTG_SERVER/api/table.json?content=sensors&output=json&columns=objid&filter_group=MYGROUP&filter_status=1&filter_status=2&filter_status=3&filter_status=4&filter_status=5&filter_status=6&filter_status=7&filter_status=8&filter_status=9&filter_status=10&filter_status=11&filter_status=12&filter_status=13&filter_status=14&count=10000&username=MYUSERNAME&passhash=MYPASSHASH
    1. Replace https://MY_PRTG_SERVER with the address of your PRTG installation.
    2. Replace MYGROUP with the name of the group whose sensor count you want to monitor.
    3. Replace MYUSERNAME and MYPASSHASH with the credentials of your user account to authenticate the HTTP request.
    4. Adjust the filter_status parameters to your needs. See below for a table with sensor status IDs.
  3. Enter the XML Node: treesize
  4. You can leave all other settings unchanged.
  5. Click Create to create the sensor.

IDs of sensor states

You can use the following internal IDs for filter_status parameters to only count sensors in a specific status:


For example, if you only want to count sensors in the Up status, only provide the parameter filter_status=3.

Monitoring sensor count with custom sensor

PRTG Tools Family provides a custom third party sensor for download that counts the number of sensors per status. This custom sensor counts also sensors in sub-groups.

Note: We do not offer support for third party sensors. If you encounter any issues with this sensor, please contact PRTG Tools Family directly.

Steps to take

  1. Download the sensor SensorCountXML from the PRTG Tools Family.
  2. Extract the files and copy the file SensorCountXML.exe to the \Custom Sensors\EXEXML subfolder of the PRTG program directory.
  3. Add the EXE/Script Advanced sensor to your PRTG installation and use the following parameters: -s=ip-address|hostname] -u=username -p=password|passhash [-r=rootID] -s = The IP and optional port number of your PRTG core server -u = Username -p = Password or passhash -r = Optional, the rootID of the probe or group you want to count from (default = 0)

The channels of this sensor show the number of sensors for each status under the root ID you specify in the parameters.


Created on Dec 21, 2015 3:07:29 PM by  Gerald Schoch [Paessler Support]

Last change on Oct 15, 2020 8:28:05 AM by  Brandy Greger [Paessler Support]



I think it's important to give a concrete example whenever possible. I am using PRTG to monitor 15,000 wireless access points across a School District in the US. For each school, I want to be able to graph the number of Access Points that are out of service over time. The best way is to track the state of associated PING sensors and count any sensor that is not in one of Unknown, Collecting or Up as indicating an Out of Service device.

I am using the RESTclient extension of Firefox for testing and my REST API URL looks as follows:


The XML returned is something like:

<?xml version="1.0" encoding="UTF-8"?>
<sensors totalcount="1" listend="1">
    <group>BocaRatonCHS 0961</group>
    <status>Down </status>

I am going to eliminate all of the returned fields except "objid" in my Sensor definition.

I created a self referential "Device", that is a Device with the PRTG servers own hostname so that it can call its own API.

I then created the HTTP XML/REST sensor. Since this is a REST sensor, the Authentication values go in the URL not in the Username and Password fields.

In the XML Node field I entered "sensors totalcount" because I want the value of the "totalcount" attribute under the "sensors" node.

The limitation I see here is that the ID of the group for which I want to count sensors is embedded in the URL ( "&id=6436" line ). I want to be able to programmatically clone this sensor and manipulate that group ID using a script. I have 180 schools to create these sensors for so this will take all day if I do it manually.

Created on Dec 7, 2018 1:36:06 PM



Dear GwigstaNummerEin,

in principle, you could try to script the sensor creation. It is possible to list all devices under a node, a script could then process that list and create all those URLs.

However, writing, testing and employing such script would probably take more time than doing it manually. I strongly advice against applying a script – which has not been thoroughly tested – to a production server. This means, a migration to a PRTG copy is in order, which needs another machine and involves extra work.

An option could be the approach to perform the API call with powershell, parse the result and return it. The PS1 file can be added to PRTG as custom Exe/Script sensor. This allows you to provide the ID as sensor parameter. Normally, this does not scale well, as only so many processes can be started without running into stability issues. But the XML/Rest sensor is actually an Exe sensor as well.

Either if you use XML/Rest, or a custom sensor, please use long scanning intervals, of at least 5 minutes.

There is another option: Clone the sensor, use the PRTG API to change its properties. These examples are for a sensor id 2123. The URL setting can be changed with


The node to read can be changed with


API calls can be performed through scripts as well, but please don't to bulk changes with an untested script on a production server.

Created on Dec 7, 2018 5:10:23 PM by  Arne Seifert [Paessler Support]



I did use the method of cloning a sensor and modifying the "xmlurl" property and I did script it. I potentially have 180 of these sensors to create so scripting it and creating a reusable python module that wraps the PRTG API is a worthwhile investment for me.

I tend to run these scripts through a debugger with break points so that I can track progress and abort if things don't look right. I haven't had any issues so far and I am in the process of getting this server ready for production so the risk is worth it. I just need to insert pauses between object creation calls because the server gets overloaded if I don't.

I did forget to drop the scanning interval and that is important so thanks for the reminder. I want this primarily for long term trend monitoring so I could maybe drop this to 15 minutes.

My plan is to build out a multiple probe environment so I might end up dedicating a probe to doing these computationally "expensive" calls.

Created on Dec 10, 2018 7:34:41 PM



Dear GwigstaNummerEin,

yes, using pauses between API calls is a good idea to prevent system overload. A PRTG API call is always done on the core server, meaning a multi-probe setup cannot be used to distribute API call system load, even if the sensors you change run on a remote probe.

Once you changed the sensor through the API, the core server updates the sensor configuration on that probe. (The sensor configuration for all sensors is stored on the core server.)

Created on Dec 11, 2018 1:38:41 PM by  Arne Seifert [Paessler Support]

Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.