api-http-monitoring title graphic

How to Combine HTTP & API Monitoring for Your Website

An API check is comprised of multiple HTTP/S checks configured for uptime monitoring. In API monitoring, tracking latency and availability provide first notice of a potential problem. The same extends to general uptime monitoring, where serving the best and fastest user experience is critical.

Functionally, an API and HTTP/S check might do the job of monitoring API endpoints. Both can post or expect strings in response, and both provide alert of downtime. However, aside from the multi-step nature of an API check, there’s an often overlooked difference between these two: their runtime. At five-minute intervals, an API check has enough time to run through its steps and gather its data before reinitiating. The HTTP/S check, on the other hand, has a much faster minimum of one-minute intervals.

Combine these performance monitoring tools and you get a more responsive system for uptime monitoring of API and other server infrastructure.

Table of Contents
  1. Advanced Uptime Monitoring with HTTP/S Checks
  2. Uptime Monitoring Examples Using HTTP/S
  3. Uptime Monitoring for Staging and Testing
  4. Performance Monitoring Tools for API
  5. General Uptime Monitoring Tips with HTTP/S and API
  6. Testing with API and HTTP/S

Advanced Uptime Monitoring with HTTP/S Checks

The HTTP/S check contains optional parameters that offer expanded usage for technical users expecting specific data or resources. The optional parameters are as follows:

  • Username
  • Password
  • String to POST
  • String to expect (Exact Match or Regular Expression)
  • HTTP Headers

For security purposes, the username and password fields should be associated with an unprivileged user account.

The HTTP(S) Check optional parameters have important limits, namely that they cannot follow up with additional requests/queries if the returned data is as expected. The check would register as either up or down with no further action.

However, HTTP(S) checks can run every minute. They can be faster for querying a specific resource in some cases than an API Check.

Looking for a solution that includes both API and HTTP/S monitoring? Try Uptime.com today, with a 21-day free trial, no credit card required.

Uptime Monitoring Examples Using HTTP/S

Now let’s look at some practical use cases for the HTTP/S check. Ideally, performance monitoring tools tell you more than whether the URL is up or down. We’ll show you how to create an alert system that delivers more specific information about what went wrong.

Verify API Endpoint Status

HTTP/S checks are great at monitoring status codes, which are one of the fastest methods we have of finding out more specifics about a particular URL.

A good strategy for API monitoring is to check on multiple API endpoints. An API check is good for modelling user behavior that fetches resources, but not for detecting whether the status is 200 OK before the check begins. Create an HTTP/S check for those endpoints, and use the String to Expect functionality to tell Uptime.com anything else you want to look for (IE: Status:200, 200, OK, AVAILABLE, etc).

You can also send a single POST request, which helps when using String to Expect to verify the response. Additionally, checks can fail when a specific string is detected. You can program such a check to issue an alert when the status code matches an expected value, such as 304 or 429. You can use this type of check to get more insight into a specific problem because it only triggers under conditions you’ve set.

Verify Tracking is in Place on a Single URL

You can use String to Expect to monitor for tracking pixels you might use for internal analytics, or to inspect other hidden elements important to development.

HTTPS check with string to expect

A sample HTTP/S check using String to Expect to check for an Analytics script

In the Optional parameters, set the String Comparison to Exact Match.
If you’ve setup a RUM check, you can test this functionality by pasting a fragment of your RUM code into the String to Expect field.

Uptime Monitoring for Staging and Testing

Very often, a production server will be used to “break” an application in an environment similar to the real world. So-called “prod” or “dev” or “test” servers offer some security in simulating the user experience without disturbing the userbase.

An HTTP/S check set to run against your testing server, with basic AUTH credentials that have no privileges associated, can help ensure that server is operating normally and experiencing no latency issues. This check would also provide first-response if a new feature crashes the server with technical data about what went wrong to shorten internal diagnosis and testing.

Performance Monitoring Tools for API

API checks use a mix of GET and POST requests that allow for advanced queries. Such a check is designed to mimic the multi-step behavior common in users, and is designed to alert administrators of latency issues, problems reaching a specific resource, and more.

Let’s say we want to verify that HTTPbin is up and running, and that it can receive commands before we ask it to post something specific. In practice, we might use a basic query like this to establish a database is ready to receive requests with a test query to confirm. You can think of this like pushing a notification with a read receipt.

We’ll need about 8 steps to finalize, since we want to be extra careful to verify every potential detail we can. This is the power of an API Check, where verification, speed, and accessibility are all essential.

Our steps look like:

  1. GET https://httpbin.org/status/200
  2. Validate status code is 200
  3. GET https://httpbin.org/get?anything
  4. Validate status code is 200
  5. Validate response contains ‘anything`
  6. POST https://httpbin.org/post with URLencoded data “testing12”
  7. Validate status code 200
  8. Validate response contains ‘testing12’

We use validators to check for a specific status code before we begin an action. Each GET request has a validator that tracks the time it takes to fulfill that request, and our POST request validates status code as well.

API Checks screenshot timeout setting

The red arrow indicates Timeout value in number of seconds

We can use the Advanced tab to further define our ideal response by setting out Timeout value. By default, Uptime.com considers the check timed out after 30, but we can raise or lower that time (in seconds) as needed to flag latency issues.

General Uptime Monitoring Tips with HTTP/S and API

Always create tiered alerting, so any element can break with ample time to alert your team of the outage. If you’re running an API check, configure an additional HTTP/S check that monitors one of your endpoints. The one-minute interval ensures alert data arrives faster with HTTP/S checks than with API checks. However, HTTP/S checks cannot use multiple steps.

The API check is designed to monitor the user experience, even mimicking a user’s actions.

API Checks uses multiple HTTP/S requests. Use it for multi-step API monitoring when you need to confirm resource availability, and be sure you’re using the check to cover for every potential performance or payload issue.

Testing with API and HTTP/S

Thanks to its advanced options, an HTTP/S check is both robust and functional. It won’t recreate the user experience the way an API check can, but it will issue downtime alerts much faster.
Combined, these checks provide detailed technical data related to downtime with API and server resources. Not only can you POST and acquire responses, you can check server status and monitor customer-facing infrastructure simultaneously.

Advanced usage of these checks can provide great peace of mind, and a more secure method of monitoring resources.

Minute-by-minute Uptime checks.
Start your 21-day free trial with no credit card required at Uptime.com.

Get Started

Don't forget to share this post!

Avatar

Richard Bashara is Uptime.com's lead content marketer, working on technical documentation, blog management, content editing and writing. His focus is on building engagement and community among Uptime.com users. Richard brings almost a decade of experience in technology, blogging, and project management to help Uptime.com remain the industry leading monitoring solution for both SMBs and enterprise brands. He resides in California, enjoys collecting and restoring arcade machines, and photography.

Catch up on the rest of your uptime monitoring news