At some point every homelab crosses a line. You go from three containers on a mini PC to a dozen services spread across two or three machines, and suddenly you have no real idea what’s happening under the hood. Is Plex about to run out of RAM? Did the reverse proxy quietly stop routing traffic at 3 a.m.? Did your ISP throttle you back to half the bandwidth you’re paying for, again? “Monitoring” is the answer everyone reaches for. But it’s not one tool doing one job, it’s three different questions with three different answers, and picking the wrong tool for the question you’re actually asking is how people end up trying to use Prometheus to check whether a website loads. That’s a bit like using a torque wrench to hang a picture frame. This guide breaks down the real self-hosted monitoring options in 2026, what each one is actually built to answer, and which combination makes sense for a homelab instead of an enterprise data center.
What “monitoring” actually means for a homelab
Before comparing tools, it helps to split “monitoring” into the jobs people actually mean when they say the word:
- Resource metrics: how much CPU, RAM, disk I/O, and network throughput a machine or service is using right now, and how that’s changed over the last hour, day, or week
- Availability checks: whether a service is reachable at all, responding to HTTP requests, accepting TCP connections, answering ping
- Observability at scale: correlating metrics across dozens of hosts and containers, querying them, building custom dashboards, and alerting on thresholds fleet-wide
Netdata answers the first question almost by itself, right out of the box. Prometheus and Grafana together answer the third, with the first as a side effect of doing it. Uptime Kuma answers the second and mostly doesn’t care about the first at all. None of these is “the best” tool outright. They solve different problems, which is exactly why most homelabs that have been running a while end up with two of the three, not one.
Netdata: real-time metrics with zero configuration
Netdata is the tool to install when you want an honest, immediate answer to “what is this machine doing right now” without spending an evening on configuration. Point the installer at a host, bare metal, VM, or a single Docker container, and it auto-discovers what’s running (databases, web servers, containers, GPUs) and starts charting thousands of metrics per second, with no dashboard to build and no query language to learn first. That per-second granularity is the real differentiator: most monitoring tools sample every 15 to 60 seconds, which is fine for long-term trends but useless for catching a five-second CPU spike that just crashed a container. Netdata’s dashboard is opinionated and pre-built on purpose. You’re not assembling panels, you’re just looking at a screen that already makes sense the moment it loads.
The trade-off is scale. Netdata is built around a single-node view; comparing metrics across twenty hosts side by side, or writing a custom query that correlates database latency with reverse-proxy error rates, isn’t really its job (Netdata Cloud extends it toward that, but that’s a separate, partly paid layer on top). For a NAS, a Proxmox host, or a handful of Docker hosts, none of that matters much. The full setup, the actual Docker deployment, and the license split between the free Agent and Netdata Cloud are covered in the Netdata guide.
Prometheus + Grafana: the full observability stack
Prometheus and Grafana get mentioned in the same breath because they’re built to be used together. Prometheus pulls (scrapes) metrics from every service you point it at on a schedule, stores them in its own time-series database, and lets you query that history with PromQL. Grafana then turns those queries into dashboards, graphs, and alerts. Between the two, this is about as close as self-hosting gets to what companies like Datadog sell as a paid product, minus the per-host billing, and you keep the data.
The honest downside is setup effort. Netdata works the moment the container starts. Prometheus needs a scrape configuration telling it what to monitor and how often, and most services need an “exporter” running alongside them to expose metrics in a format Prometheus understands: node_exporter for host-level metrics, cAdvisor for container metrics, and so on. Grafana then needs Prometheus added as a data source, and dashboards either built from scratch or imported from the community library. None of this is genuinely hard, but it’s an afternoon of work rather than five minutes, which is why this stack gets described as “more setup effort” next to Netdata.
What you get back is real scale and flexibility. One Prometheus instance can track metrics from every container, VM, and service in a homelab. PromQL lets you ask specific questions like “what’s the 95th percentile response time for this container over the last six hours.” Grafana’s alerting can notify you before a disk actually fills up instead of after. The official Prometheus documentation is worth reading directly if you’re deciding whether the query language fits how you think about your infrastructure. For the actual Docker images, a working scrape configuration, and how the two connect in practice, see the Prometheus and Grafana guides.
Uptime Kuma: uptime and availability, not resource metrics
Uptime Kuma solves a different problem than the two tools above, and it’s worth being explicit about that because it trips people up: it doesn’t know or care how much RAM a container is using. What it cares about is whether a service actually responds. HTTP/HTTPS checks, TCP port checks, ping, DNS, and a growing list of specific integrations (Docker container status, gRPC, MQTT). Point it at a reverse proxy, a DNS server, a media server, or anything public-facing, and it polls on a schedule, logs the response time, and flags the exact moment something stops answering.
Two things make it worth running even alongside Prometheus and Grafana. First, public status pages: Uptime Kuma can generate a shareable page showing the live status of whichever services you choose, the same idea SaaS products publish during an outage, except self-hosted and under your control. Second, notifications. It ships with more than 90 built-in integrations (Discord, Telegram, ntfy, email, and most of the usual suspects), so a phone alert the moment something goes down is a five-minute setup rather than a separate Alertmanager configuration. It runs from a single Docker container and, unlike Prometheus, gives you something useful within minutes of starting it rather than after an afternoon of configuration. Installation steps and notification setup are in the Uptime Kuma guide; the project’s GitHub repository is worth a look too if you want a sense of how actively it’s maintained. It’s one of the most-starred self-hosted projects on GitHub for a reason.
Specialized monitoring: Changedetection.io and Speedtest Tracker
Not every monitoring need fits neatly into “resource metrics” or “is it up.” Two tools solve narrower problems well enough that bending a general-purpose tool into doing their job instead isn’t worth the effort.
Changedetection.io monitors web pages for changes rather than servers for health. Point it at a product page and it flags when the price drops or an item restocks. Point it at a changelog or a terms-of-service page and it flags when the content actually changes. It supports visual diffing and CSS/XPath filters to watch just one part of a page, plus a headless browser option for JavaScript-heavy sites that a plain HTTP check would miss entirely. It’s a different niche from server monitoring, but it comes up often enough in self-hosted monitoring conversations that it’s worth knowing it exists.
Speedtest Tracker does one thing and does it well: it runs Ookla’s Speedtest CLI on a schedule and charts the results over time, download, upload, ping, and packet loss. If you suspect your ISP throttles connections at certain hours, or you’re about to call and complain about a slow connection, this is the tool that hands you a graph instead of a hunch.
Resource overhead: what each one actually costs
This matters more in a homelab than it does in a data center, because the machine running the monitoring stack is usually also running everything being monitored. Netdata is lightweight per host but can get RAM-hungry if metric retention is pushed up high on a machine already tight on memory; the default settings are usually fine for anything with 2 GB of RAM or more to spare. Prometheus is the heaviest of the three by a clear margin, mostly because its time-series database keeps everything locally and indexing that data isn’t free. On anything monitoring more than a handful of targets, giving Prometheus 1-2 GB of RAM and some dedicated disk space is realistic. Grafana itself is light. Uptime Kuma is the lightest by far. It’s checking whether things respond, not ingesting a metrics firehose, and it runs comfortably on hardware that would visibly struggle to run Prometheus and Grafana together.
Which one should you actually run?
Realistically, most homelabs that have been running for more than a few months end up with two of these three, not one. A practical way to decide where to start:
- Managing one to three machines and wanting an honest picture of what’s happening right now, with no setup? Start with Netdata. It’s the fastest path to an actual dashboard.
- Running a dozen-plus containers or services across multiple hosts, and wanting to correlate metrics, build custom dashboards, or set threshold-based alerts? Prometheus + Grafana is worth the extra setup time, and it’s the stack most likely to still make sense as things keep growing.
- Caring more about knowing the instant a service goes down than how much RAM it used beforehand? Uptime Kuma is the more direct answer, and it’s usually the first monitoring tool people actually install, because it takes minutes rather than an afternoon.
- Need to track a web page instead of a server, or a bandwidth number instead of a container? Changedetection.io or Speedtest Tracker will do that one job better than any general-purpose tool bent into shape for it.
None of these choices are mutually exclusive, and that’s really the takeaway. Uptime Kuma watching whether things are up, paired with either Netdata or Prometheus and Grafana watching why they went down, covers the two questions that actually matter day to day in a homelab: is it broken, and what broke it.