HTTP(S) Check Basics

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

Return

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 minute to 1 hours, 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 elf-signed certificates.

Basic Setup

Return

The required attributes for an HTTP(S) check include:

  • Check interval
  • Locations
  • Contacts
  • 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 

Monitor a Single Publicly Available API Endpoint

Return

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:

  1. Create an HTTP(S) check to monitor httpbin.org/post
  2. Click the Optional tab, and fill in the String to Post field with “penguin”
  3. Fill in the String to Expect field with “penguin”

HTTPs POST.png

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. 

Monitor a CDN via Assets It Loads

Return

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. 

Create an HTTP(S) check and utilize String to Expect to look for important assets that the CDN is responsible for loading, such as CSS or Javascript. Static assets, such as fonts or scripts that do not change by session, are excellent candidates for monitoring your CDN.  

HTTPs string.png

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.

Use a Host Header to Connect to IP Addresses Directly 

Return

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:

Host: YOURURL.com

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. 

Monitoring a Proxy

Return

You can run your check via a HTTP or HTTPS Proxy by entering a complete proxy URL such as http://user:pass@myproxy.com:8888 into the Optional field, Proxy URL. 

HTTPs Proxy.png

 Creating a Custom User-Agent

Return

In some situations, it may be necessary to pass a custom user-agent to your check. A user-agent can be used to identify web traffic among other things. You can pass your own custom user-agent header to your HTTPS check by utilizing the HTTP Headers field under the Optional settings of your HTTPS check.

Please note, you may send one header per line, in regular HTTP format.

Special note for monitoring Shopify stores: Recent changes to Shopify’s security policies may cause some HTTPS checks to fail when monitoring Shopify stores due to blocked user-agents. For monitoring these stores, we recommend adding a user agent to something unique like "shopname" or "yourdomain":

 

Pass an Access Token

Return

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:

HTTPs Headers.png

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:

HTTPs comparison.png

Failed Checks

Return

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:

uptime-alert-email.png

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:

alert-details.png

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

Return

Before you finalize your check, click Run Test to verify your settings are returning the expected results. 

run-test-https.png

Before saving, every HTTP(S) check must have the following:

  • Name
  • 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.

test-select-location.png

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.

Other Commands

Return

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.

A Note on Checker Versions

Return

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:

HTTPs SSL_TLS.png

Use Cases and Examples

Return

You may use our Secure Vault to securely store your details. For more information review our support doc.

Was this article helpful?
2 out of 4 found this helpful

Comments

0 comments

Article is closed for comments.

Have more questions?
Submit a request
Share it, if you like it.