The smallest monitoring script in the world

If you want to read this article in german please visit our website monitoring magazine.

In this article, we want to try out the smallest monitoring script in the world, just for fun. We've got it down to three lines. Nevertheless, it includes an analysis of the HTTP status code, reacts on broken SSH certificates and sends alerts via email if necessary.

#!/bin/bash
if [ `curl -I "$1" | grep 'HTTP/2 200' | wc -l` != 1 ]; then
    mail -s "Alert: problems curling $1" $2 < /dev/null
fi

The call is then as follows:

./up.sh https://www.koality.io alarm@koality.io

That was it. In principle, a few things happen here at once:

• We make a curl request on the first parameter passed on the command line. Here it is important to include the -I parameter because we are only interested in the headers and especially the status code.
• After that, we use grep. We check if the output of the curl call contains an HTTP/2 200.
• The wc -l call only counts how often the HTTP/2 200 occurs. As soon as it does not occur, the alarm case occurs. The good thing is, if the URL is not reachable at all, curl throws an error and the status is not found either. Lucky in misfortune then.
• Last step: we send an email on the command line to the email address we defined as the second parameter. Very simple.

What is missing?

It is almost always like this: Getting started with a certain topic is easy and maybe even achievable with three lines of code. But if you seriously deal with it, a lot of details come to your mind, which the simple approach cannot solve yet.

• continuous testing - Of course we want to run all tests continuously. Preferably every five minutes. Automated.
• distributed testing - If our little script can't reach the server, there is a 50/50 chance that the error is in your own hands. So you would have to run the same test again from a different data center to make sure that the error is on the side of the website you want to examine.
• other status codes - Our script can currently only check for status 200. But it can be very useful to check other status codes as well. For example, you could include important redirects (301) or non-public pages (403) in the monitoring.
• Channels - e-mail is so 90s. It would be nice to get the messages via Slack, Microsoft Teams or other channels.
• Error messages - So far the body of the email is still empty. We would have to change that and also add some details that we are not collecting yet.
• Status change - The script sends an error message via email every time a website is not reachable. It would be more correct if you would only be informed when the status changes.
• Hosting - The whole thing can't run locally, since it's running around the clock. Furthermore, it cannot run in the same data centre as your own systems. In case of a failure, both systems would be unreachable and no alarms would reach the responsible persons.

If you implement all these points, you have certainly learned a lot about monitoring websites and know many pitfalls. But it can be easier to buy this uptime monitoring service because then you have all this immediately out-of-the-box and can take care of your own task: developing websites.