Health checks

The health checks feature allows you to supplement your deployment models with HTTP-based health checks to get an "at a glance" view of the health of your software systems. Here is an example.

Health checks

How it works

When defining your software architecture model using the client library, HTTP-based health checks can be added to the Container Instances in your deployment model. Each health check is defined by a name, an endpoint URL, a polling interval (e.g. 60 seconds), a timeout (e.g. 1000 milliseconds), and optionally one or more HTTP headers.

When the workspace is loaded into your web browser, the health checks are executed and the results are summarised by colour coding the diagram elements (red, amber, green) and indicating the percentage of the health checks that have passed for each element.

Health checks
Health checks

The health checks are executed from within your web browser, so HTTPS URLs must be used (rather than plain HTTP). Also, the response sent back from your servers must include the Access-Control-Allow-Origin header, to allow the cross-origin request to be made. Returning anything other than a HTTP 200 status code will cause the health check to be marked as failed.

The health check endpoints can either be existing endpoints, or custom ones that you build into your applications. For example, you could add a /health endpoint to an existing web application that simply returns a HTTP 200 response to indicate that it's okay. Alternatively, you could build a more complex collection of health endpoints that check whether the back-end data stores are accessible.

Usage scenarios

The health check feature is not designed to replace monitoring systems such as Pingdom, New Relic, Nagios, etc. Instead, it can be used to augment existing information radiators and dashboards, to provide an "at a glance" view of whether the software system is running and which parts are down in the event of a failure. It can also be used in diagnosing problems with a given deployment environment.