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 setup once you’ve logged in. The following tutorial will assume you’re logged into Uptime.com.
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, with optional parameters that provide additional functionality.
HTTP(S) Check: Check Uptime.com Speed Test, and verify Google Analytics is Working
The goal will be to check that the free Speed Test tool is working on Uptime.com, and utilize the “String to Expect” command to go one step further and verify our Google Analytics is working. If a problem occurs with our tracking, this type of check will alert us immediately.
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
This test will use HTTP GET to visit Uptime’s Speed Test page, then check for a specific string of text in the code as a verification method.
For a detailed breakdown of each Parameter, please visit the Field Explanation support article.
This check will visit “https://uptime.com/freetools/website-speed-test” and expect the string “window,document,'script','//www.google-analytics.com/analytics.js','ga'” to be present on the page. If that value is not present, or the URL is unreachable, the monitor check will fail.
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 a 404 error, and reports the Analytics script isn’t running either.
Login to Uptime.com and visit the dashboard for instant access to reports. Review report details 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 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
- Select “Website HTTP(S)” Check Type
- Enter a URL
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.
Although these fields are optional, they have some useful properties that may apply to your particular uptime check. For detailed definitions, please refer to the Field Explanation support article.
- String to POST
- HTTP Headers
Some advanced options provide added functionality to HTTP checks that webmasters and IT teams may find valuable.
- Use IP Version