Why I Dumped Uptime Kuma for Healthchecks.io (and How It Changed My Monitoring Game)

When I first stumbled onto Uptime Kuma a couple of years ago, I was sold on its clean look and the promise of a one‑click Docker install. For a while it did exactly what I needed – ping a handful of home servers, fire off Discord notifications, and keep a simple dashboard alive on my NAS.

But as the list of devices grew, the cracks started to show. The notification system felt brittle; I could only pick from a few preset services, and any custom webhook required me to edit JSON by hand. The UI, while pretty, became sluggish after a dozen monitors, and there was no real way to group checks into logical projects. I tried to patch it with community plugins, but each tweak added another layer of complexity that I wasn’t prepared to maintain.

That’s when a fellow developer nudged me toward Healthchecks.io – the open‑source service originally built for cron‑job monitoring but now a full‑blown uptime solution. At first I was skeptical; after all, it’s marketed for “scheduled tasks,” not for ping‑based HTTP checks. A quick dive into the docs proved otherwise: Healthchecks supports HTTP(S) endpoints, TCP ports, ICMP pings, and even custom scripts, all wrapped in a clean, responsive interface.

Setting it up was eerily straightforward. I spun up a docker-compose.yml file with three services – healthchecks, redis, and postgres – and ran docker compose up -d. Within minutes I had a login screen, an API key, and a dashboard that looked half‑finished, half‑awesome. The installer prompted me to set a “ping URL” for each check, which felt more natural than the “monitor type” dropdown I’d wrestled with in Kuma.

Migration was a bit of a manual process, but not the nightmare I feared. I exported my monitor list from Kuma as JSON, then wrote a short Python script to transform each entry into Healthchecks’ API payload. In the end I had all my home‑lab services – Plex, Home Assistant, a few Docker containers, and even my personal website – humming along in the new system.

The payoff was immediate. Notifications now flow to every channel I use: Discord, Telegram, email, Slack, and custom webhooks, all configurable per‑check without diving into raw JSON. The built‑in “incidents” tab groups failures by project, so when two services go down together I instantly see the bigger picture. I also love the “grace period” feature, which lets me define a timeout window before an alert is fired – something that used to require a kludge in Kuma.

Performance-wise, Healthchecks runs lean. The Docker container uses roughly 150 MB of RAM on my Raspberry Pi 4, compared to the 300 MB that Kuma tended to chew up once I hit a dozen monitors. The UI stays snappy, even after I added a couple of dozen checks, and the background worker process scales nicely with Celery if I ever need more horsepower.

Of course, no tool is perfect. Healthchecks doesn’t have the built‑in “visual ping map” that Kuma showed off at launch, and its mobile layout could use a bit of polishing. Still, the trade‑offs feel minor compared to the reliability boost I now enjoy.

Bottom line: If you’re already comfortable with Docker and you want a monitoring solution that grows with you – complete with granular alerts, clean incident tracking, and a surprisingly low resource footprint – give Healthchecks.io a spin. I’ll keep tweaking my setup, but for now I’m glad I finally said goodbye to Uptime Kuma.