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: Check that Tag Manager is Working
- Use Case: Use a Host Header to Connect to IP Addresses Directly
- Use Case: Pass an Access Token
- Use Case: Monitor a Proxy
- 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
The goal will be to check that our testing site is OK 200, and we’ll use “String to Expect” to go one step further and verify our Google Analytics is working by looking for our tracking ID. You can use this type of check to verify that tracking pixels are working as intended on your site.
We will need to fill in the following details:
- The name of our check
- Our check interval (We will use a 1 minute interval for this example)
- The URL we wish to check (You will note this is the only “Required” value)
- A string of text that the check should expect to see
For a detailed breakdown of each Parameter, please visit the Field Explanation support article.
This check will visit “https://www.w3schools.com/” and expect the string “UA-3855518-1” to be present on the page. If that value is not present, or the URL is unreachable, the monitor check will fail.
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 would allow you to monitor these servers with the HTTP check.
You will need:
- An 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:firstname.lastname@example.org: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 checking for 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: