Creating a low maintenance server(less) status page
A server status page is an important tool for online games. It is used to inform players about planned or unplanned backend outages. There are several cloud-based products available like Atlassian Statuspage, but those are rather expensive for what they do and you would have to use a vendor specific API to automatically report incidents.
Scope of this post
There is need for a simple static (meaning low maintenance) status page without vendor lock-in which can be run in a serverless environment. This post presents a solution based on the open source project cstate.
Alternatives
In order to avoid vendor lock-in, I have previously used Cachet, which is an open source status page based on PHP and an SQL database. However, Cachet basically requires a server, and this server can also be down.
Deploying Cachet on Kubernetes simply is too much installation pain and also requires maintenance (due to the nature of “PHP and SQL” based software). Therefore, Cachet not considered in this post.
Why use a static page?
A status page should be there when you need it and show outages, but other than that it should require zero maintenance. If it is a dynamic page, there will be security issues you need to care about. Regular updates to the page software and its environment would be required.
In addition to that, a large number of players might hit the status page at once if there is an outage. Similar to that, you might want to show a feed of the status page within the game.
The page should be able to easily handle high load.
A static page fits all these requirements: It consists of static html (mostly no security issues) and does not cause additional load other than serving these html files.
Static incidents
Server incidents and outages are, of course, dynamic content. At first sight it seems counterintuitive to serve this kind of content using a static page. How does it work?
The basic concept is that incidents are managed in a git repository, and the static page is automatically updated from that git repository. This means that security mostly depends on your git repository, and you usually need a secure repository anyway (so this does not cause additional maintenance).
Creating a cstate status page
cstate uses the static website generator Hugo, which is supported by several providers for continous deployment. The provider polls for git changes and automatically regenerates the static website. In this post, we are using AWS Amplify, but for example Netlify also supports Hugo pages.
The following steps need to be done to create your own status page:
- Clone https://github.com/cstate/example (recursively), change the project name, template files and incidents according to your needs.
- Push the result to your own git repository (private or public).
- Feel free to test the result locally by running “hugo server -D” within the repository directory. In order to do this, you need to install Hugo: Hugo releases
- Publish the status page by following the instructions: Hugo and AWS Amplify using your newly created repository.
- Enjoy your serverless status page.
Where to go from here
Incidents can be created by adding files to the content/issues directory in the git repository. This can be done manually or in a serverless function using e.g. https://github.com/go-git/go-git/. Simply clone the repository to temporary storage, add an incident file, commit and push.
Limitations
If you rely on automatically updating existing incidents, things can get tricky, because you need to parse and change existing incident markdown files.