Uptime Kuma: Your Free Website Monitoring, in One Evening

The StartingUp Summer keeps mapping out the year gone by. After containerizing a Next.js application to host it on our own VPS, we stay on the ground of infrastructure independence: this time, it's your website monitoring moving under your own roof, with Uptime Kuma.

Your site goes down on a Friday at 7 p.m. Who notices first? In many companies, the answer is: a customer, Monday morning, by phone. Between the two, a whole weekend of lost visitors, silent forms, and doubts sown about how serious the company is. Knowing in thirty seconds that your site has stopped responding, before your customers do, is an insurance policy that costs almost nothing. You still have to take it out.

Uptime Kuma, an open-source, self-hosted tool, offers free, unlimited website monitoring: HTTP checks as often as every twenty seconds, alerts across more than 90 channels (Slack, Telegram, email), and public status pages. It runs in a simple Docker container, on an entry-level server. What's left is understanding what you're installing, and the traps even a good tool doesn't cover.

The natural instinct, though, is to subscribe to a specialized service: UptimeRobot, Pingdom, Better Stack and a few dozen others do this very well. But their business model bills per monitor and caps check frequency, while a small server for a few euros a month does better, with no meter running. Here's how we approach the question, and how to build your own monitor in one evening.

Let's be clear upfront that these services are solid, reliable, and that a free account with one of them is infinitely better than nothing. The friction lies elsewhere: everything that makes monitoring genuinely useful (checking more often, watching more things, alerting on more channels) drives the bill up. As we write this, the rough figures are as follows:

That's the SaaS logic: you pay for usage, and the usage that matters here is precisely the kind you'd want unlimited. Yet an uptime monitor is a tiny program. Sending an HTTP request every thirty seconds and checking the response code demands neither a beefy processor nor bandwidth: the smallest VPS on the market, at three or five euros a month, can watch over dozens of sites effortlessly. So the real question isn't whether it's technically possible, it's whether a tool exists that makes it as comfortable as a SaaS. It does.

Uptime Kuma is an open-source project that has become one of the references in self-hosting, with a very active community; the 2.x branch, at version 2.4 as we write this, has turned it into a mature product. It can check a URL over HTTP(S), look for a keyword on a page, test a TCP port, a ping, a DNS record, or the state of a Docker container. It logs history and response times, manages maintenance windows, and publishes public status pages you can share with your customers or your team. On the alerting side, it claims more than 90 notification channels: Slack, Telegram, email, Discord, SMS through various providers, webhooks...

On a server with Docker installed, deployment comes down to one command:

Or, if you prefer the declarative version, a minimal docker-compose.yml:

Then head to port 3001 of your server (ideally behind a reverse proxy with HTTPS), create the admin account, add your first monitor: two minutes, start to finish. Wiring up Slack or Telegram comes down to pasting a webhook or a token into a form, and check frequency goes down to twenty seconds if you feel like it. None of the limits in the table above apply anymore: they were never technical, they were commercial.

If even a Docker container feels opaque to you, here's the experiment that shows there's no magic to it. An uptime monitor, stripped to its essence, is this:

Drop this script on any machine that's always on, add a cron line like */2 * * * * /opt/monitor/check.sh, and you'll get a notification on your phone (via the free ntfy app, here) within two minutes of an outage. Five lines of shell: that's the core of the service platforms bill per monitor.

This bare-bones approach has a cost, obviously: no history, no second attempt before alerting, no interface, no status page. That's exactly the value Uptime Kuma adds on top. But having written this script once changes how you see things: you now know what you're buying, and what you can decide to host yourself.

The classic beginner's trap: installing the monitor on the same server as the site. When the server goes down, the alarm goes down with it, and no one rings. The monitor has to live elsewhere: another VPS, ideally with another host or in another datacenter, so that one outage doesn't blind the other. Which leaves the dizzying question: who watches the watcher? Our pragmatic answer: a free UptimeRobot account pointed... at our own Uptime Kuma. The irony isn't lost on us, and neither is the redundancy.

The dumbest outages aren't server outages. An expired TLS certificate on a Sunday shows a security warning to every visitor: the site is "up", but nobody gets in anymore. Uptime Kuma watches certificate expiry and can alert several days in advance: turn that on, always. Domain name expiry, on the other hand, isn't natively covered as far as we know: automatic renewal at the registrar, a valid payment method, and an early reminder remain the only real safeguard. A lost domain is far harder to recover than a restarted server.

A single timeout isn't an outage: the network has its moods, and a site can take eleven seconds to respond once a day without that deserving a midnight wake-up call. Configure the number of retries before alerting (two or three consecutive failures), space out notification resends, and resist the urge to pile on channels. An alarm that cries too often ends up ignored, and an ignored alert is worse than no alert at all: it gives the illusion of being covered. A reliable alert in two minutes beats a jittery stream every thirty seconds.

Let's sum this up from a decision-maker's point of view: for the price of a coffee a month and one evening of setup, you'll always know before your customers that your site is down, your certificate will renew before it expires, and you'll have a status page to show when someone asks. This isn't a technical project, it's a risk-management decision, and probably the one with the best return of everything we describe in these pages.

The exercise has a secondary virtue we're fond of: like hosting your own applications, taking back control of this link teaches you what it actually contains. A subscription is something you put up with; a tool you host is something you understand. And the day your phone buzzes at 7:04 p.m. for an outage that started at 7:03 p.m., you'll know exactly what those few euros are worth.