Standardizing Application Status APIs

If you work with multiple SaaS applications, online services or APIs eventually one of them is going to be unavailable due to planned or unplanned outages. Most of these services have status pages, which are a great way to manually check the status, but it is still manual. What is needed is a standard API for checking the status of a service and components.

If services had standard APIs for checking status it would make it simple for applications to notify users if a external service they depend on is offline. Another major use case would be for application administrators to have an aggregate dashboard so at a glance they could quickly check which services are offline as well as have automated notifications to employees when business critical applications are offline.

The issue is that for many companies status pages are an after thought and for some services they may not want to have other sites tracking their error rates as it is something competitors may be able to use to their advantage. As a consumer of online services I would see it as positive if a service provided not just a status page, but an API to check if service is online.

An ideal service API would be consist of few standard calls.

/status
General Service Status for All Service.

/status/services
Listing of individual Services with Statuses.

/status/services/:servicename
Individual Service Status.

An example of return objects would be.
serviceName : “Example Service”,
status : “offline”
resolutionEta : “2 hours”

In a perfect world an advanced use case would be web hooks that could be registered when services change status.

The issue with status pages and APIs is they are best hosted on external server or services that would not be affected by application issues or internal/private network issues, because if the application goes down and the status page & service is offline then it