Uptime

The world's smallest uptime monitoring script

Website Monitoring Magazine

We have already explained in detail how classic uptime monitoring looks like. In this article, rather for fun, let's try our hand at the world's smallest monitoring script. We have brought it down to three lines. Nevertheless it contains it analyzes HTTP status code, reacts to broken SSH certificates and sends alerts via email when necessary.

The script

#!/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's about it. Basically, a few things happen at once here:

  • We make a curl request on the first parameter passed on the command line. Here it is important to pass the parameter -I, because we only get

are only interested in the headers and especially the status code.

  • After that grep is used. We check if there is a HTTP/2 200 in the output of the curl call.
  • The wc -l call only counts how often the HTTP/2 200 occurs. As soon as it does not occur, the alert occurs. The good thing is that if the URL

is not reachable at all, curl throws an error and the status is not found either. Luck in the misfortune therefore.

  • Last step: we send an email on the command line with mail to the email address we defined as second parameter.

Simple.

It's nice that you are reading our magazine. But what would be even nicer is if you tried our service. koality.io offers extensive Website monitoring especially for web projects. Uptime, performance, SEO, security, content and tech.

I would like to try koality.io for free

What is missing?

It's almost always the case that getting started with a particular topic is easy, and maybe even achievable with three lines of code. However, if one seriously with it, a lot of details come to mind that the simple approach can't solve yet.

  • Continuous testing - We naturally want to run all tests continuously. Preferably every five minutes. Automated.
  • Distributed testing - If our little script can't reach the server, then there's a 50:50 chance that the error lies with you. So

you would have to run the same test again from another data center to make sure that the error is on the side of the website you are investigating. website to be examined.

  • Other status codes - Our script can currently only check for status 200. However, it can be very useful to check for other status codes as well.

For example, you could include important redirects (301) or non-public pages (403) in the monitoring.

  • Channels - Email is so 90s. Would be nice to get the messages via Slack, Microsoft Teams or other channels as well.
  • Error messages - So far the body of the email is still empty. That would need to be changed and also include a few details that we don't now

not yet collected.

  • Status change - The script sends an error message via email every time a website is down. It would be more correct to be informed only

when the status changes.

  • Hosting - The whole thing can't run locally, because it is in use around the clock. Furthermore, it cannot run in the same data center

as the own systems. In case of a failure, both systems would not be accessible and no alarm messages would reach the responsible persons. reach those responsible.

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 service, because then you have all this immediately out-of-the-box and can take care of your own task: developing websites. Developing websites.

If you like this article, please subscribe to our newsletter. After that you will not become one of our articles about monitoring and agencies.

Yes, I want to subscribe to your newsletter