Simple Ways to Improve your Health Endpoints

Most of our applications today have a pretty simple health endpoint:

That actually just tell if your app is running or not. But if your app is ok, but your databases connections are in a bad shape, this route will not be able tell you.

This post describes some tips on how to improve your health endpoints, regardless the language/framework you use.

Return a JSON with your healthdata

Only sending a 'ok' or 'not ok' may not be totally useful for whoever consumes your health endpoint. Instead, you can return a JSON with every status of the checks you do, being more precise on what's going on with your app.

Assuming you'll do the checks mentioned in this post, this can be an example of the response of your endpoint:

Also, remember to properly set the HTTP status of the response to match your application status (200 when everything is ok and a 503 when things are in a bad shape).

Check your DB connections

Whether you use PostgreSQL, MongoDB or any other database, one important thing to check is if your DB is alive and well or if your connections are getting a timeout.

MongoDB, for instance, has a ping command that is able to check if your connection is alive. Remember to wrap this call in a timeout block like this example:

With this check, you can ensure your DB is responding in time.

Check your Redis connection

This is extremely important if you use any background job processing tool like Sidekiq , which uses Redis to manage its data.

Redis has the same ping command I mentioned for MongoDB, but in this case it returns the string " PONG" .

With this you'll be able to make sure your app is ready to process your background jobs.

And about it…

Check the latency of the queues of your background jobs

This check can provide you an insight of your workers: if you have jobs getting stuck for some unusual and bizarre reason.

The mentioned Sidekiq offers you some very handy methods for checking the latency of any queue: