My UptimeRobot free plan pinged my API every 5 minutes. When a deploy broke things at 14:02 and recovered at 14:04, I got zero alerts — the whole outage fit between two checks. To actually see sub-5-minute incidents they wanted $15/month for 50 monitors at 30-second intervals.
That's $180/year for what is, mechanically, curl in a loop.
The $0 replacement
Uptime Kuma, self-hosted, running on the same Oracle Cloud Always Free ARM VM (4 OCPU, 24GB RAM — yes, really free forever) that already hosts three other tools:
docker run -d --restart=always \
-p 3001:3001 \
-v uptime-kuma:/app/data \
--name uptime-kuma \
louislam/uptime-kuma:1
Total install time: 4 minutes. The UI is better than the paid tool I replaced, which stings a little.
6 months of data, side by side
| Metric | UptimeRobot free | UptimeRobot paid ($15/mo) | Uptime Kuma ($0) |
|---|---|---|---|
| Check interval | 300s | 30s | 20s (mine) |
| Monitors | 50 | 50 | unlimited (I run 40) |
| Status page | 1, branded | 3 | unlimited, unbranded |
| Discord/Slack alerts | 1 integration | all | 90+ notification types |
| Cost / 6 months | $0 | $90 | $0 |
| Incidents detected | 3 | ? | 11 |
That last row is the whole argument. In 6 months Kuma caught 11 incidents — 8 of them were sub-3-minute blips (a bad canary deploy, two OOM restarts, a TLS cert renewal hiccup) that a 5-minute check interval would never have seen. UptimeRobot free caught only the 3 long ones.
My status page told users "100% uptime" while I shipped 8 invisible outages. That's not monitoring, that's marketing.
The catch (there's always one)
- Your monitor is also your liability. If the VM dies, nobody watches the watcher. My answer: a $0 Healthchecks.io free tier cron pings Kuma itself from the outside. If Kuma goes quiet for 10 minutes, Healthchecks emails me. Monitoring all the way down.
-
No managed SLA. If Oracle reclaims my idle VM (they've warned about this for capacity reasons, mine hasn't been touched in 6 months), I lose history unless I back up
/app/data. I rsync the volume nightly to my laptop — 40MB, takes seconds. - You're the on-call for the monitoring tool itself. Kuma updates, docker restarts, disk space — all yours.
What I'd do differently
I'd have migrated on day one instead of month 14. The 5-minute blind spot cost me a real incident in April — users reported an outage my status page swore never happened.
I'm drafting my tooling setups like this one with MonkeyCode — the free AI coding assistant I keep recommending: https://ly.cyberserval.tech/iIETXiF
What interval are you actually monitoring at — and have you ever checked whether your outages fit between the pings?
Top comments (1)
Self-hosting can absolutely be a good fit, but one monitor running on one VM has a very different reliability model from distributed external monitoring.
If that VM, provider, or network disappears, your monitoring can disappear with it. The interesting comparison isn’t really the cost of running a curl loop, but what it takes to reproduce independent locations, reliable alert delivery, redundancy, and the maintenance around all of that.