Use a custom HTTP status code for your apps' healthchecks

To have systems up & running is something, but to have them healthy it’s another story.

If you are looking to implement healthchecks in your architecture beware of being a bit too simplistic: you might configure, for example, on of your frontend machines to check the status of the backend ones every few seconds, so that nginx or haproxy can remove the backend if they find it unreliable / unhealthy.

Problem is, there might be tricky situations in which the backend responds with a 200 Ok even though it’s not working1.

There are a lot of ways to avoid this, but the simplest one, that takes you 2 minutes and works quite well, is to use a custom HTTP status code for your healthcheck page – we use 211 Healthy.

For example, in node, we would do:

Serving response with a custom HTTP status code in NodeJS

and then we would need to tell our backend that the only status code that has to be considered healthy is 211.

No more, no less.

  1. For example, the backend’s nginx can just respond with nginx’s default welcome page, if your host is misconfigured

Hi there! I recently wrote an ebook on web application security, currently sold on leanpub, the Amazon Kindle store and gumroad.

It contains 160+ pages of content dedicated to securing web applications and improving your security awareness when building web apps, with chapters ranging from explaining how to secure HTTP cookies with the right flags to understanding why it is important to consider joining a bug bounty program.

Feel free to skim through some of the free chapters published on this blog and, if the content seems interesting enough to you, grab a copy on leanpub, the Amazon Kindle store, gumroad or simply checkout right down below!

Buy the Web Application Security ebook for $9.99

In the mood for some more reading?

...or check the archives.