This article will cover the setup and purpose of the HTTP(S) functionality built into Uptime.com. This basic check is the most common check utilized by Uptime users, and most likely the first check you will set up after logging in. The following tutorial will assume you’re logged into Uptime.com.
Table of Contents
- Adding Your First HTTP(S) Check
- Basic Setup
- Use Case: Monitor a Single Publicly Available API Endpoint
- Use Case: Monitor a CDN via Assets it Loads
- Use Case: Use a Host Header to Connect to IP Addresses Directly
- Use Case: Monitor a Proxy
- Use Case: Pass an Access Token
- Failed Checks
- Finalizing Your Check
- A Note on Checker Versions
Adding Your First HTTP(S) Check
To add a new HTTP(S) Check, click Monitoring followed by Checks, and then Add New. Select Website HTTP(S) from the Check Type drop-down menu.
HTTP(S) checks monitor a specific web or IP address to ensure the URL response code is 200 OK, in intervals ranging from 1-60 minutes, with performance reporting and alerts. Optional parameters provide additional functionality.
Please note: the HTTPS check will follow a maximum of 15 redirects. The HTTP(S) check also supports self-signed certificates.
The required attributes for an HTTP(S) check include:
- Check interval
- URL or IP address
First, set your check’s minimum monitoring interval and then select which probe server locations Uptime.com will use to monitor. You can add contacts to the check to determine which email address, SMS, phone number or integration will receive an alert if this check reports an outage.
HTTP(S) Check Use Cases
This use case will involve monitoring httpbin and detecting a string is returned. We will make a POST request and expect a response. Setup looks like this:
- Create an HTTP(S) check to monitor httpbin.org/post
- Click the Optional tab, and fill in the String to Post field with “penguin”
- Fill in the String to Expect field with “penguin”
Select a test server if you desire, and then click Run Test to verify the POST was made and the server returned our expected result. If the returned result differs from the string we expect, or the server code is not 200 OK, we will receive an alert.
The HTTP(S) Check (version 2.0) can help when monitoring a CDN for uptime and responsiveness. You will need more than one HTTP(S) check for increased precision, and each HTTP(S) check will require at least 5 locations for the most accurate possible monitoring.
Multiple locations are important since they trigger the CDN to load assets from different regions, thereby providing a picture of performance and uptime with accurate geographical data.
When using a load balancer, you may have multiple servers behind a single endpoint/IP address. Or if using DNS failover, you may have multiple DNS records for the same host. Using a host header and the IP address directly allows you to monitor these servers with the HTTP check.
You will need:
- A HTTP(S) Check for each IP address your load balance utilizes
- The “Host” header
Create a check that uses the IP of a server. Go to the Optional tab, and enter the following into the HTTP Headers field:
If the check fails, you will receive a notification for the IP address of the server that failed, providing more specific insight into how your load balance is faring.
You can run your check via a HTTP or HTTPS Proxy by entering a complete proxy URL such as http://user:email@example.com:8888 into the Optional field, Proxy URL.
An authentication token identifies a user, and is a popular alternative to basic authorization. While still not fully secure, its alternative method of identifying a user is useful in certain situations. This type of check will monitor a URL that requires an authentication token for up or down status, offering first alert capabilities for a variety of uses.
We’ll use HTTPbin for this test. Monitor httpbin.org/bearer with a test token you create. Our example is below:
We can take this a step further with RegEx. HTTPbin prints the token we’re looking at on its next page. If we know the length and the character contents, a simple regular expression can find what we’re looking for:
We have multiple options for viewing reporting related to a check. The first contact, and preferred notification method, was defined when you created your Uptime account. You were asked to enter the email and extended contact information for the individuals to notify on your team. If a check fails, these contacts will receive notifications of failure by default.
You will receive an automated message informing you that the URL is “down,” alongside a response code, and location codes from the probe servers used in monitoring the check. You will also see which checks failed in the description of the downtime event. Notice our warning informs us the server is returning 200 OK, but the string we’re expecting is not present:
Login to Uptime.com and visit the dashboard for instant access to reports. Review real-time analysis to see more technical data about the problem. In this case, we’ve instructed our check to look for a non-existent page:
We will fix our check and wait for testing to indicate the website is back up. Uptime’s next check will observe the URL is now functioning, and run the validation we defined. Uptime will send our contacts a new message informing us the site is back up, and the total length of downtime.
Finalizing Your Check
Before you finalize your check, click Run Test to verify your settings are returning the expected results.
Before saving, every HTTP(S) check must have the following:
- Defined interval
- Contacts - Choose a specific list of contacts that should be notified
- Locations of probe servers from which to test (Use a minimum of three probe servers)
- Select “Website HTTP(S)” Check Type
- Enter a URL
Before finalizing your check, utilize the Run Test button to verify your settings are returning the expected results. To run a test, select from any of the probe server locations available to your account from the Location dropdown and click Run Test.
This check will run automatically with no need for further input on our end. We can respond to incidents as they happen, and edit the parameters of this check as needed to change the string to expect, or any other value.
In addition to the check itself, you can schedule routine maintenance downtime, or control how long it takes to escalate downtime events.
Please take a moment to familiarize yourself with the Uptime Checks Field Explanation Support Article. We’ve also included a notes section in this Check for any additional information you’d like to save for future reference.
1.0 HTTP(S) Checker and 2.0 HTTP(S) checker
The HTTP(S) checker has two versions to utilize. The legacy version is a standard HTTP(S) check that monitors a URL or IP address for OK 200. The 2.0 version is based on cURL and it supports certificate verification for SSL/TLS, as well as HTTP/2, SSL v3 and chunked content.
Please note: the HTTP(S) check can handle self-signed certificates. However, it is important users utilizing self-signed certificates turn Verify Certificates to Off as depicted below: