Building mOps: The power of using Runscope to create automated system health checks

This is the third article in the the building mOps (modern ops process) series, if you like this article, please subscribe to know about our upcoming blog posts. This was originally posted on SYNQ’s blog.

Here at SYNQ, as an API based company, we must always ensure our APIs are functioning as expected. Runscope is one of the core tools that we use for conducting actual tests against our APIs.

Setting up a test is very simple. All we have to do is set up a post request to any of our APIs and make assertions on the JSON response given back by our system. From there, we can configure additional settings such as a schedule of how often we want the test to run, as well as the geo locations we want the test to be ran from.

To give an example of this, let’s walk through how we created a test for our Query API (/v1/video/query). First we created a post request to our Query API, which requires that we supply an API key and a filter. The API key is simply a way to authenticate with our API and the filter is a piece of JavaScript that will be ran against all the video objects within a project:

After this, we configure the assertions for our Query API test, the assertions define how we establish that a specific request has passed. They can be as simple as checking for a specific HTTP status code response or even a whole script to verify a request has passed. In our test, we verify that the Query API returns the proper HTTP status code, has the proper header information and verify that a few JSON fields in the body response are not empty:

As seen in the assertions above, the expected response should return at least one video that includes a video_id, a created status and the embed JSON fields. None of these fields should be empty. Assuming these assertions pass, then we know that the Query API is working as expected.

Setting up the alerting

Once a test has been added, we turn on the various alerts we want. We already have the integrations needed within Runscope. So it is only a matter of turning on the integrations we want associated with a particular test in the editor. For our Query API test, we turned on our PagerDuty Query check and our Slack integration.

With these two alerts, our team and clients will be informed should our Query test start to fail. Our team is alerted since PagerDuty will call or text various team members based on our escalation policy and it will also alert our customers through our Pagerduty and StatusPage integration. Additionally, since our whole team uses Slack for communication, we are also alerted if there are tests failing.

Setting up test locations and a schedule

Once we had the alerts set up for our Query API test, the last part is setting up a schedule and the location we want our test to be ran from. First, we choose the geo locations that the Query API test can run from:

In our case we ended up choosing 4 different geo locations. Next, we set up a schedule to tell the Runscope how often we want our Query API test to run:

The test should be ran every hour, given that we already had other tests for the Query API that run more often. We can very easily modify the schedule with just a few clicks.

The Power of Health Checks with Runscope

Now that we had our health check for the Query API setup, we know that if there are any problems, the appropriate team will be alerted and our customers will also be made aware if there is an issue. This gives us the ability to be transparent with our clients and also increases our efficiency in resolving problems that may arise. The power of doing health checks with Runscope is that the steps are repeatable for testing all of our APIs. If a new feature is added, it can become part of our current automated testing scheme as soon as the feature is released or even before its made public.