My Simple Approach to App Health Check with Automation

Scripting + Cron.

Image credit: https://pixabay.com/illustrations/blood-pressure-monitor-check-test-3934879/

This is included in the “My Innovative Solution to Test Automation and Continuous Testing” series.

Below is a definition of “App (software) Health Check”:

“Health Checks give you the ability to monitor the health of your application by writing a small tests which returns either a healthy, degraded or un-healthy result. This is useful not only to test the internal health of your application but also it’s external dependencies such as an third party api which your application relies on to function correctly.” — source

There are two ways to implement App Health Check.

• Using a commercial service, such as AppDynamics.
  Besides cost, it is usually complex and over-engineered. Most apps don’t need that.

• Self-created utility
  and run it regularly.

I prefer the latter because it is usually quite easy if adopting correct approaches. Sadly, most software companies did not do that well, commonly either over-engineered or not reliable.

During test automation consulting, there have been a few cases where someone requested me to write automation scripts for health check purposes. This article shows my (simple yet effective) approach and shares an app-health-check report for my own apps/services.

App Health Check Design Options

A gold rule of App Health Check: 100% automated, without human interventions.

1. Check what?

There are three types of checks:

• The app instance (i.e. server) is up and running.
  Typically, checking HTTP status code.
  
  Suggested tech stack: a ‘NET/HTTP’ library.

• The app’s service status is a valid one
  This might need to extract text from a specific element on a web page.
  Unlike a simple HTTP status code check, session handling might be required.
  
  Suggested tech stack: a headless browser simulator library, such as mechanize.

• Quick smoke end-to-end checks
  Go through a few key End-to-End (via UI) scenarios. The main purpose is to make sure all dependent infrastructure, such as database, queueing, email servers, and third-party services, is working. One important note: all the scenarios must leave no side effects; in other words, they are read-only type operations.
  
  Suggested tech stack: Selenium WebDriver in headless mode. (Chrome and ChromeDriver are required).
  
  The pros are obvious, but the cons should be considered seriously: slow, less reliable, and more dependencies (browser and its driver).

2. When and How Often?

As a general rule, do it at the off-peak time, e.g. dawn time, and every day.
The primary advantage of maintaining regularity is that in the event you fail to receive notifications, it could indicate a potential issue with the service-checking machine/scripts itself.

3. Notification

• By Email
  The simplest way. I recommend it.

• Push to A team group chat system like Slack
  It is also quite easy to integrate push notifications into a group chat system. However, I don’t recommend this approach as people tend to get fancy and overreact.

My Approach

Here is what my service check report (in an email) looks like: