There are so many ways to do this but below are some examples and will help get started.
Types of HTTP Error and Status Codes:
100-199: informational status
200-299: success status
300-399: redirection status
400-499: client errors
500-599: server errors
HTTP and HTTPS Monitors which matches a range of HTTP 1.0 or 1.1 status codes from 200 to 306: HTTP Monitor: Type: HTTP Parent Monitor: http Send String: GET / HTTP/1.1\r\nHost: yourwebsite.com\r\nConnection: Close\r\n\r\n Receive String: HTTP/1\. 0[0-6]
HTTP and HTTPS Monitors which matches an HTTP 1.0 or 1.1 response with a 200 status code: HTTP Monitor: Type: HTTP Parent Monitor: http Send String: GET / HTTP/1.1\r\nHost: yourwebsite.com\r\nConnection: Close\r\n\r\n Receive String: HTTP/1\. 200
Please replace yourwebsite.com with the actual hostname of your website.
Receive String: Just some quick examples HTTP/1\. 0[0-6]Accepts 200-206 and 300-306 – everything else like 4xx and 5xx results in a non-matching value and will fail the check HTTP/1\. 0[0-6]Accepts only 200-206 HTTP/1\. 200Accepts only 200
Can you use (200) by itself in the “Receive String”?
Yes, you can use `(200)` as the “Receive String” for the HTTP/HTTPS health monitor.
However, keep in mind that this will search for `(200)` anywhere in the response, not just in the HTTP status code. This means that if `(200)` appears anywhere in the body or headers of the response, the health check would be considered successful.
If you specifically want to match the 200 status code, you should use a more specific regular expression like `HTTP/1\. 200`. This will ensure that you are indeed matching the HTTP status code, not some other part of the response.
Also remember that the “Receive String” field is case-sensitive and must match exactly the string in the HTTP response body. It interprets regular expressions, which allows for pattern matching.
GET vs HEAD
The use of `HEAD` for HTTP and `GET` for HTTPS in the monitor setup was just one example of how you could configure the monitors, but it’s not a strict requirement. The choice between `GET` and `HEAD` depends on what you want to achieve with the health check.
The `HEAD` method is identical to `GET` except that the server does not return the message-body in the response. When you use `HEAD`, you’re asking the server to respond as it would to a `GET` request, but to leave off the actual content of the resource. This can be a useful method for performing a quick check to see if a resource is available, without having to transfer the entire resource, which might be large.
The `GET` method, on the other hand, requests the entire resource content from the server. This could be used if you want to ensure not only that the server is responding, but also that it’s serving content correctly.
In the context of an HTTPS monitor, `GET` is often used because the monitor is already going through the overhead of setting up an SSL/TLS connection, so it makes sense to perform a full check of the resource content while it’s at it.
That said, you could choose to use `GET` for both the HTTP and HTTPS monitors if you want to confirm that the server is properly serving content, or `HEAD` for both if you’re only interested in confirming server responsiveness. The methods can be used interchangeably based on your specific needs.
How to test HTTP Status Codes and get Data from the Site: