Review: Uptime Kuma After 6 Months of Self-Hosting
What is Uptime Kuma
Uptime Kuma is a self-hosted uptime monitoring tool. You point it at your services — websites, APIs, ports, Docker containers — and it pings them on a schedule. When something goes down, it tells you via Telegram, Discord, email, or about twenty other channels.
It’s the self-hosted alternative to UptimeRobot, and it’s free.
Who this review is for
I’m a solo person running a handful of services for myself and a few clients. If you run a large infrastructure team, this review won’t tell you much — you already have Prometheus and Grafana and a pager rotation.
This is for people who want to know when their personal server or side project went down, without paying a subscription.
How I ran it
- Version: 1.23.x, updated monthly
- Environment: Debian 13, Docker Compose, 2 GB RAM
- Monitored: 18 endpoints (HTTP, TCP, Docker container health)
- Notifications: Telegram primary, email fallback
- Duration: 6 months at the time of writing
What’s genuinely good
Setup is ten minutes. Install via Docker, open the web UI, click “Add monitor,” paste a URL. That’s it. There’s no config file to learn and no query language to memorize.
Notifications are the best part. It supports an absurd number of channels, and Telegram works flawlessly. I get a message within 30 seconds of something going down. For a one-person operation, that’s the whole product.
The UI is clean and fast. Not beautiful, but clean. You can glance at it and know the state of everything in two seconds.
It’s lightweight. The container uses about 60 MB of RAM. You can run it on a Pi or a cheap VPS without noticing.
Free and self-hosted. Your monitoring data stays on your server. No third party knows which of your services exist.
What broke
The database. Uptime Kuma uses SQLite by default, and after about 4 months of monitoring 18 endpoints, the database file grew to around 400 MB. Queries got noticeably slower — the dashboard took 3-4 seconds to load instead of instant.
I solved it by switching to PostgreSQL, which is supported and documented. But it’s an extra step the “ten minute setup” doesn’t mention.
No alert grouping. If three services on the same host go down simultaneously, you get three separate notifications. For 18 endpoints this is annoying but manageable; for more, it would be a problem.
No real historical analytics. You get uptime percentages and a status page. You don’t get “which hour of the day do my services tend to fail” or “is this a weekly pattern.” For that you’d need something heavier.
Status pages are basic. The public status page works, but it looks like 2015 and you can’t really brand it.
What it does not do
Worth being clear, because “monitoring tool” sets expectations it does not meet.
No escalation policy. There is no “if I do not acknowledge in ten minutes, page the second person”. For a one-person lab that is irrelevant; for a small team it is the reason people move to Grafana OnCall or PagerDuty.
No metrics history. Uptime Kuma answers “is it up” and “how long was it down”. It does not answer “was the disk at 92% before it filled”. That is Prometheus territory, and running both is normal — the Prometheus and Grafana walkthrough covers the other half.
No multi-user permissions worth the name. Everyone who can log in can change everything. Fine for a household, not fine for a shared box where a flatmate should not be able to delete your checks.
Status pages are basic. They work, they are useful for “is the media server down for everyone or just me”, and they will not replace a branded status page with incident history.
None of this is a complaint. It is a small tool that does one thing properly, and knowing the boundary is what stops you from being surprised at 2am.
A note on the host: this runs in an LXC container on the hypervisor reviewed in Proxmox VE after a year, which is also where the resource graphs come from when a container starts eating RAM.
Pros and cons, summarized
Pros:
- Ten-minute setup
- Excellent notification support
- Lightweight (60 MB RAM)
- Free and self-hosted
- Clean, fast UI
Cons:
- SQLite database grows fast and slows down
- No alert grouping
- Limited historical analytics
- Status pages are visually dated
Best for / Skip if
Best for: self-hosters, solo developers, and small teams who want cheap, reliable “is my stuff up?” monitoring with good notifications.
Skip if:
- You need alert grouping or sophisticated routing (look at Prometheus + Alertmanager)
- You want deep historical analysis
- You need a polished, brandable public status page
- You monitor more than roughly 50 endpoints — at that scale, manageability becomes the issue
Alternatives
- UptimeRobot — hosted, free tier exists, less control
- Better Uptime — polished, paid, great status pages
- Prometheus + Grafana + Alertmanager — the serious answer, but a completely different complexity class
- Blackbox Exporter — if you’re already in the Prometheus world
Verdict
For a self-hosted monitoring tool at this price point (free), Uptime Kuma is hard to beat. The notification system alone is worth it, and the resource usage means you can run it basically anywhere.
The SQLite slowdown is a real annoyance, but it’s documented and fixable. Everything else is just the cost of using a simple tool instead of a complex one — and for most self-hosters, that’s a trade worth making.
I’d recommend it without hesitation to anyone monitoring under 30 endpoints. For anything larger, set it up, but keep a migration plan in your head.
References
- Uptime Kuma GitHub repository — source, releases, and issue tracker
- Uptime Kuma wiki — notification channels and setup
FAQ
Is it really free?
Yes. There's no paid tier, no limits, no "contact sales." It's open source.
Can it monitor Docker containers?
Yes, both via HTTP/TCP checks and by reading container health status. I monitor both.
What happens if Uptime Kuma itself goes down?
Then nothing monitors anything, and you get no alert about it. This is the classic "who watches the watcher" problem. I run a second lightweight check from a different server for the most critical endpoint.
Should I switch to PostgreSQL immediately?
If you monitor more than 10 endpoints or plan to keep history for more than 3 months, do it during setup. It saves you a migration later.