I use some of PRTG’s Web Server (HTTP) sensors. I am not sure if I have to configure the sensors to show a determinate sensor status when receiving a determinate HTTP status code. Is there a rule for that?
This article applies to PRTG Network Monitor 17 and later
How a PRTG HTTP Sensor Reacts to HTTP Status Codes
The HTTP sensors show their status depending on the HTTP status codes that they receive.
By default, the sensor states are the following:
|HTTP status code||HTTP sensor status|
|2xx Success||Up (Green)|
Note: Except for status code 200, the REST Custom sensor defines all other 2xx states as down status.
|3xx Redirection||Warning (Yellow); Down (Red) for too many redirects|
|4xx Client Error||Down (Red)|
|5xx Server Error||Down (Red)|
You need to configure your HTTP sensor(s) manually only if you want to change these default reactions. In this case, you can change the sensor status based on limits and/or keyword checks.
If you're looking for an alternative where you can adjust the behavior to "accept" a specific HTTP Code (for example, sensor green on HTTP 403) then you will need to use a Custom Sensor. For example:
For several checks, I don't want to a 3xx redirect to mean Warning or Down. How do you override these sensor-state/status-code relationships?
@dcsgpvan: Overriding these value/state pairing is not possible currently. However, you might have a look at this script which could probably be extended.
Hi. We are evaluating PRTG and came across the same issue. This being an old thread - is it still valid?
We have a web service that will reply 403 to PRTG, as the request is not fully qualified with the right data for that service (changing that behaviour is not trivial as we will need to add special support to that code to use a specific header or something). I tried to use the "HTTP advanced" (and all other HTTP), hoping that if I use "dont alarm if text exists in reply" - it wont alarm. Yet it does, as it's 403.
All I wan't to know is that some service is listening/answering on "http://IP:port/". Is there another way?
Unfortunately, a HTTP error will also always show an alert within PRTG. This is how the sensor is designed and intended for.
You can try adding a "Port Sensor" with the Port "443" and activated "Use Transport-Level Security (default)"-option.
That worked (tho with the "Do not use Transport-Level Security (default)" - as this is HTTP on port 80 and not HTTPS on 443).