Self-hosted UptimeRobot alternative: monitoring you own with Uptime Kuma

Monitoring has one job: be the thing that notices when everything else fails. That makes it a strange service to rent, because hosted monitoring platforms meter exactly the properties that make monitoring useful -- how many monitors you can create, how often they check, how many people get alerted, and whose domain your status page lives on. The free tiers are generous right up until your infrastructure starts to matter, and then every new service you watch and every minute you shave off the check interval moves you up a pricing page. The status page your customers bookmarked during the last outage sits on the vendor's domain, which means leaving costs you the one URL you most need to keep. Uptime Kuma is the version you own.

What Uptime Kuma is

Uptime Kuma is an open-source uptime monitor created by Louis Lam, and one of the most popular self-hosted projects on GitHub, with more than 60,000 stars. It watches your services, records their response times, alerts you when they break, and publishes status pages -- all from software running on infrastructure you control.

The monitor types cover most of what actually needs watching. HTTP and HTTPS checks confirm an endpoint answers and answers correctly. TCP checks confirm a port is open, which covers databases, mail servers, and game servers that never speak HTTP. Ping and DNS checks catch problems below the application layer. Keyword checks assert that a page actually contains what it should, not merely that it returned a status code. And push monitors invert the whole model for the jobs nothing can probe from outside: a cron job or backup script pings Uptime Kuma when it succeeds, and silence past the expected interval becomes the alert.

When something does break, it can reach you through more than 90 notification services -- Telegram, Discord, Slack, email, and plain webhooks among them -- so alerts arrive wherever your team already lives instead of in one more inbox nobody watches. Status pages, response-time charts, and certificate expiry warnings are built in rather than sold as add-ons.

The features that actually matter

• Push monitors for the jobs nobody watches. Backups, certificate renewals, and nightly cron jobs fail silently by design -- there is no endpoint to probe, so most monitoring never sees them. A heartbeat monitor makes the silence itself the alert. If the backup did not check in by 04:00, you hear about it at 04:01 instead of on the day you need the backup.
• Keyword checks catch what a status code hides. A page can return 200 with an empty template, a database error rendered politely, or a maintenance banner. Asserting the page contains the string it should contain is the difference between monitoring the server and monitoring the service.
• Certificate expiry warnings. An expired certificate is the most preventable outage there is, and it still happens everywhere, because the expiry date lives in nobody's calendar. Uptime Kuma warns you days ahead, on every HTTPS monitor you already have, for free.
• Status pages on your own domain. An outage is exactly the wrong moment to depend on a third party for communication. A status page you host, at an address you own, keeps working for you no matter which vendor relationship changes -- and it is the URL your customers keep forever.
• Response-time history. Most outages announce themselves in advance as a slope: responses drifting from 80ms to 400ms over a week. The charts make degradation visible while it is still a task, before it becomes an incident.
• No quota shaping your coverage. Hosted tiers train you to ration -- monitor the five things that matter most, check every five minutes because every minute costs more. When adding a monitor is free, you monitor everything, and the obscure internal service that quietly died in March gets noticed in March.

What it's like to run

Uptime Kuma is one of the easiest self-hosted applications there is. It ships as a single container with an embedded database, and setup is a first-run wizard in the browser: create an admin account, add your first monitor, done. There is no configuration file to learn and no external database to stand up. Its resource footprint is small enough to sit beside your other apps without being noticed, which is fitting for software whose job is to run quietly for years.

The operational questions are the standard self-hosting ones: putting HTTPS and a sensible domain in front of it, keeping it updated, and backing up its data so your monitor history and notification settings survive. And one question specific to monitoring: where it runs. A monitor that shares fate with the things it watches has a blind spot exactly where you need it not to -- if the region goes down, the thing that would have told you goes down with it.

Running it on Caliber Node

Uptime Kuma is in the Caliber Node app catalog. One click deploys it, and it is answering on its own HTTPS subdomain in minutes, behind Cloudflare, with a custom domain attachable whenever you want the status page on an address you own. It runs inside the capacity subscription you already have, alongside your other apps -- deploying it is not a new line item, just a slice of capacity you have already paid for.

Its data lives on your own volume, reachable over SFTP and covered by snapshots, so the monitor history and configuration are yours to back up, inspect, or take elsewhere.

And the fate-sharing problem has a direct answer here, because region choice on Caliber Node is per app, not per account: deploy the monitor in a different region from the things it watches. A monitor in Amsterdam watching apps in Detroit sees a Detroit problem from the outside, the way your users do -- instead of disappearing into it.

Hosted monitoring keeps asking what your uptime is worth to you, monthly, per monitor. A monitor you own answers the question once. Deploy Uptime Kuma, point it at everything you run, and let the meter be something it watches rather than something you pay.