Documentation

HTTP Checks

About HTTP Checks

HTTP is the transfer protocol for web pages, as well as being used for some other web based technologies. It is by far the most common check on NodePing. HTTP is a request-response protocol. The client, in most cases in daily life a browser, sends a request to a server and the server sends a response back, hopefully with the information the user was hoping to get. The response includes a header component and a content component. The content component is the part of the response people see in their browser. It's the part that contains the HTML. The response header includes a status code, which shows up to users most often as a 404 error. The most common status code is 200, which means the request worked and the server is responding with the requested information. For the normal HTTP checks, the NodePing system sends a request to the target URL, and watches for the status code to come back. If it gets a status code between 200 and 399 back within the threshold time, the check result is a PASS. This check type completely ignores the content of the response.

When to use HTTP Checks

You should use HTTP checks anytime you want to know if a web page is up and responding normally. However, HTTP checks just look at the status of the response, not at the actual content of what is returned. If you need to know that the web page is not just up, but responding with the right content, use the HTTP Content check instead. HTTP checks are the check of choice for most "is it up" checks on web pages. The fact that it only looks at the status in the response can also be useful in checking other HTTP based services beyond just web pages. For example, it can be used to check SOAP or other web services that respond with JSON or XML.

Using HTTP Checks

To set up a HTTP check,

1. Select HTTP from the Check type drop down.
2. Give it a friendly label to identify this check in lists and notifications.
3. Enable Automated Diagnostics if you'd like detailed technical info about the failure that may help you troubleshoot a failure.
4. Set how often you want the check to run in the Check Frequency field.
5. Enter the target URL you want to check. It must be a valid URL, starting with either http:// or https://. Any valid URL will work fine, including basic authentication, port numbers, and query strings. If you use the authentication feature for this check, or otherwise include confidential information in your checks, please keep our Terms of Service in mind and limit the access provided by the credentials you use. Usually you can just go the page you want checked and copy and paste the URL from the address bar in your browser. The following examples are all valid (although these are fictitious, don't actually use these URL's in your checks):
   • http://www.example.com
   • http://couchdb.example.com:5984
   • https://www.example.com/foo/bar.html
   • http://www.example.com/foo/bar.html?this=that&eggs=green
   • https://sam:secret@www.example.com/foo/bar.html?this=that&eggs=green
   • http://[2606:c700:4020:11::53:4a3b]/
6. To force an IPv6 resolution for the FQDN in your URL, change the dropdown from "(Default IP resolution)" to "Force IPv6 resolution". If you're unsure, the default is what you want.
7. If you want the check to follow redirects and evaluate the redirect URL change the 'Redirects:' drop down to "Follow redirects".
8. Set a time out. The default 5 seconds works fine for most situations.
9. Set the Sensitivity. High is usually appropriate. Some web hosts have intermittent periods of time when they don't respond quickly. For a visitor this might not be a big deal if it is intermittent, but it might mean you'll get more "FAIL" responses than you anticipate. In those cases, set the Sensitivity lower.
10. Set the notifications for this check. More information about notifications.

Other considerations

People who have sites on shared hosts are sometimes surprised when they get down notices and their site seems to be working ok. The performance of shared web hosts depends a lot on the traffic going to other sites on the shared host. It is often necessary to tune the Sensitivity and timeouts a little to get the balance right so you get notices when you want them, but not when the site is performing normally.

When following redirects, there is a 4 redirect limit then the check will fail withe the following error "Too many redirects".

The threshold timeout applies for all redirect requests and responses, not just the last HTTP request.

IPv6 URLs require the bracket formatting such as http://[2606:c700:4020:11::53:4a3b]/

SSL/TLS certs are not validated by this check so it will work fine for expired and self-signed certs. You'll want to add an SSL check to verify your SSL certs and get warnings before they expire.

SSLv3/TLS1.0 are not supported.