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.
To add a new HTTP(S) Check, click Monitoring, 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 self-signed certificates.
The required attributes for an HTTP(S) check include:
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.
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:
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.
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.
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:
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.comIf 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:pass@myproxy.com:8888 into the Optional field, Proxy URL.
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 in the Validation & Security tab of your HTTPS check.
You can add additional headers in this field, one per line.
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.” This will bypass the security policy and allow monitoring of your Shopify store, as well as associating the traffic with a custom user-agent that can be referenced in your logs.
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.
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.
Before saving, every HTTP(S) check must have the following:
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:
You may use our Secure Vault to securely store your details. For more information review our support doc.