Today I am going to share with you a cool free utility to monitor remote servers that you can even remotely host.
If you haven't tried it yet, a while ago I released one of the tools I created to make sure my backup witness nodes were not falling behind. It is incredibly useful for backup witness nodes and witnesses who don't produce blocks as often, and want to make sure your witness is ready when your turn comes. You can find out about it here.
Remotely monitoring servers isn't a new thing, and in fact there are plenty of services that can do this for free or really cheap. Uptime Robot is the one I would recommend for most people. The free edition is very generous but does have a minimum delay of 5 minutes.
Introducing Uptime Kuma
Uptime Kuma is completely free and draws a lot of inspiration from the Uptime Robot commercial service.
Setting it up is super easy if you are familiar with Docker. I recommend checking out their demo so you can get a feel for it before investing any time setting it up.
Running Uptime Kuma is as easy as running this command.
docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1
Although I recommend using a Docker Compose file. I'm not going to get into how to setup Uptime Kuma, as there are lots of good tutorials and I would rather tell you what you can do with Uptime Kuma.
While most of my monitors are simple Ping monitoring, if server is unavailable, send me a notification, some are more complicated. For example, you can see here HiveSQL State failed, this is a check runs a SQL query against HiveSQL and looks to see how old the data is, if it is older than 60 minutes, it will fail. I also run a simple ping check to see if HiveSQL is available.
On my witness nodes, I check for ping responses, but I also run heartbeats as explained in the post I referenced above. My Monitor Witness script recommends using HealthChecks.co for free, but Uptime Kuma also offers Heart Beat monitoring allowing you to use your Uptime Kuma instance to run these checks.
Uptime Kuma supports a lot of native monitors right out of the box and recently just added support for Browser Engine which is a big deal.
One type of monitor is looking for a keyword, this involves visiting a website, and looks for the presence (or absence) of a keyword to see if the site is functionality as it should be. If you use Vue though, the site is completely Javascript and won't display expected data unless you emulate a browser, this is where Browser Engine comes in. For example, PeakD is Vue, if you were to view the source code, or use a typical keyword monitor, all it would see is this.
<!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><meta http-equiv="X-UA-Compatible" content="IE=edge"><meta name="viewport" content="width=device-width,initial-scale=1"><title>PeakD</title>![]()
Please enable Javascript support in your browser and reload this page.
</body>html>
You couldn't tell if the site is displaying posts, or functioning correctly without using a full browser. As I discussed before, I also use database queries as checks to verify the database is not only available, but displaying up to date information.
I use Uptime Kuma to monitor a ton of services, all of which I could easily do with Uptime Robot for fairly cheap, but I much prefer hosting my own services without restrictions.
For me, living in a region that gets pretty bad snow storms, I know I will lose power during the winter 0-4 times each year. As such (and for security reasons), I will not host anything that requires 24/7 up-time from my house.
I personally have a dedicated server for this, I can justify the expense so it isn't a major concern for me. If you are on a budget though, there are some providers who will host limited docker containers for free. Fly.io is a good example of a provider that offers limited free hosting for docker containers, enough to host multiple Uptime Kuma instances in two different data centers.
At this time, there is one limitation of Uptime Kuma that many of us have been trying to resolve. At this time there is no synchronization between Uptime Kuma instances, nor is there distributed monitoring. This means you cannot use two or more locations to confirm a service unavailable until alerting you. This is one of the powerful features of commercial services and 99.9% of the time isn't a major issue. You might get a few false alerts over the course of a couple years depending on how reliable the service you use to host your instance is.
Securely chat with me on Signal
Why you should vote me as witness
