Every self-hoster eventually asks the same question: “Is my server OK right now?”

The answer used to require setting up Prometheus, node_exporter, cAdvisor, and Grafana. Four components, YAML config files, PromQL queries, and a few hours of dashboard building before you could see a single CPU graph.

In 2026, there are simpler options. This guide reviews the 7 best server monitoring tools for a fleet of 1-20 servers, what each costs in RAM and setup time, and which combination makes sense for your setup. Every tool here is self-hosted and open source, so the only cost is the small server it runs on. (Updated June 2026.)

How I compared these: RAM and footprint figures come from each tool’s own documentation plus independent 2026 benchmarks; every price and free-tier limit was checked against the vendor’s own pricing page in June 2026. Where a tool’s marketing number and real-world measurements differ (Beszel’s “under 10MB” agent, for example), I note both.

At a Glance: Which Server Monitoring Tool to Pick

Short on time? Here is the verdict before the details.

Short version: most people running 1-20 servers should deploy Beszel and add a second tool only when they outgrow it. The rest of this guide tests each one on RAM, setup time, and what it actually monitors, plus the supporting tools (cAdvisor, Gatus) and heavyweights that round out a real stack.

Why Self-Hosted Monitoring Beats SaaS for 1-20 Servers

Every tool in this guide is a self-hosted monitoring tool, and for a fleet of 1-20 servers that is usually the right call for two reasons: cost and data ownership.

Hosted monitoring is priced per host. Datadog Infrastructure starts at around $15 per host per month, Netdata Cloud’s paid Business plan is $4.50 per node per month, and Grafana Cloud bills $8 per additional 1,000 active metric series. A single Docker host can generate 5,000+ series, so three or four boxes push you into real money fast. A self-hosted monitoring pod is a flat $3/mo on InstaPods and watches as many servers as you point agents at.

The other reason is privacy. With self-hosted monitoring, your CPU graphs, process lists, and logs never leave a machine you control, instead of being ingested by a third-party SaaS. The big platforms (Datadog, New Relic, Dynatrace) are genuinely powerful for large estates, but for a homelab or a small VPS fleet they are expensive overkill. The open-source dashboards below answer the same “is my server OK” question for a fraction of the price. If you are new to running your own apps, open-source hosting and the self-hosted apps directory are good starting points.

Beszel: The Lightweight Server Monitoring Default (10MB Agent)

Beszel is a server monitoring tool built as a single Go binary. It tracks CPU, memory, disk, network, and Docker container stats with a clean web dashboard. As of v0.18.7 (April 2026) it is the lightweight default most self-hosters reach for first.

Why it’s popular: The agent uses roughly 10-15MB of RAM at idle. Beszel markets it as “under 10MB,” and independent 2026 benchmarks measure it between about 12MB and 23MB depending on the box. Even at the high end, that is a fraction of Netdata (200-500MB) or a full Grafana stack (500MB+). On a Raspberry Pi or cheap VPS, that difference matters. This is the lightweight monitoring agent the rest of the list is measured against.

Setup time: Under 5 minutes. Deploy the hub, run the agent on each server with a single command, and monitoring starts immediately. No configuration files, no query languages, no dashboard building. Running it manually means a docker-compose hub plus an agent per server; on InstaPods it is a one-click $3/mo deploy.

What it monitors: CPU, memory, disk, network, temperature, GPU usage (NVIDIA via NVML/nvtop, with experimental Apple Silicon support), per-container Docker stats, systemd service metrics, S.M.A.R.T. disk health, and detailed disk I/O (utilization, await, queue depth). It stores historical data so you can look back days or weeks. Several gaps people assume Beszel has are now closed: systemd service monitoring, S.M.A.R.T. disk health with failure alerts, and disk I/O detail all shipped in the v0.17-v0.18 releases.

What it doesn’t do: No arbitrary application-defined custom metrics (the open feature request henrygd/beszel #731 is not shipped as of v0.18.7), no PromQL queries, no log aggregation, and no AI anomaly detection. The dashboard layout is fixed, so you can’t build custom charts. If you need application metrics or a query language, pair Beszel with Prometheus + Grafana. For deeper disk-health monitoring than Beszel’s S.M.A.R.T. page, NAS and large-array owners can add Scrutiny (MIT, ~100-200MB with its InfluxDB backend) for historical SMART trends and Backblaze failure-rate context; for most single-disk setups, Beszel’s built-in alerts are enough.

Best for: Homelabs, small VPS fleets, Docker-heavy setups, and anyone who wants server monitoring without the complexity. Choose Beszel when you want resource metrics for 1-20 servers with near-zero overhead, and outgrow it when you need application metrics, PromQL, or log search. You can deploy Beszel on InstaPods in one click for $3/mo.

Netdata: The Deep Metrics Platform

Netdata is the opposite end of the spectrum. It collects over 2,000 metrics at one-second resolution with AI-powered anomaly detection.

Resource cost: Netdata agents use 200-500MB of RAM per node. The Netdata Cloud free Community tier covers 5 nodes. Beyond that, the paid Business plan costs $4.50 per node per month (billed annually).

Setup time: 10-15 minutes for the agent install. Cloud signup adds another 5-10 minutes. Customizing alerts and dashboards requires editing YAML configuration files.

The overwhelm problem: Netdata shows 2,000+ charts by default. For most self-hosters who just want to know “is my CPU OK and is Docker behaving,” this is information overload. You’re scrolling through charts you’ll never look at to find the three metrics you actually care about.

Best for: Teams that need deep observability, one-second resolution, or AI anomaly detection across complex infrastructure. If you’re running a production SaaS with 50+ nodes, Netdata’s depth is genuinely useful. Compare Beszel vs Netdata for a lightweight-vs-deep breakdown.

Dozzle: The Docker Log Viewer

Dozzle solves a completely different problem: reading Docker container logs. It’s not a metrics tool, it’s a log viewer with a web UI.

What it does: Streams real-time logs from all your Docker containers in a clean interface. Supports regex search, JSON log auto-detection, and multi-host viewing. It can also query logs with SQL using DuckDB under the hood. The v10.0 release (February 2026) added webhook alerts and a redesigned notifications page, and Dozzle now supports Kubernetes in addition to Docker and Swarm.

What it doesn’t do: No CPU/memory/disk metrics. No historical metric graphs. No threshold alerts for resource usage. If a container is silently eating all available RAM without logging about it, Dozzle won’t catch it.

Why it pairs with Beszel: This is the most common self-hosted monitoring stack in 2026: Beszel for metrics (“something is using too much CPU”) and Dozzle for logs (“let me read the error messages to find out why”). Both are lightweight, both take minutes to set up, and together they replace what used to require Grafana + Prometheus + Loki. Compare Beszel vs Dozzle for the metrics-vs-logs split.

Best for: Anyone running Docker containers who needs to quickly check logs without SSH-ing into the server and running docker logs.

Best Docker Monitoring Tools: Beszel, Dozzle, and cAdvisor

If your servers are mostly Docker hosts, three tools cover the job, and you have already met two of them.

Beszel gives you per-container CPU, memory, and network stats inside its standard dashboard, with zero config and the same ~10-15MB agent. Dozzle handles the other half: real-time container logs with regex and DuckDB SQL search, so you read the error instead of SSH-ing in for docker logs.

cAdvisor is the third option and the most misunderstood. It is Google’s open-source container-metrics daemon (Apache-2.0, roughly 50-150MB resident). It reads each container’s Linux cgroup data and exposes raw, Prometheus-scrapeable per-container CPU, memory, network, and filesystem time-series. That is the one job none of the lightweight tools do. But it ships no dashboard of its own, so you still need Prometheus to store the data and Grafana to see it. Pair it with node_exporter (the host-metrics equivalent) and you have rebuilt the exact four-component stack Beszel removes. cAdvisor is the right answer only when you specifically want queryable container metrics in an existing Prometheus setup.

One 2026 note: enterprise Docker monitoring is shifting toward eBPF and kernel-level tools (Datadog, Sysdig, Dynatrace) for zero-instrumentation container visibility. Powerful, but far past what a homelab or small VPS fleet needs.

Grafana + Prometheus: The Enterprise Standard

The Grafana + Prometheus stack is still the gold standard for production monitoring. It’s infinitely customizable, supports thousands of data sources, and powers monitoring at companies like Spotify and GitLab.

The cost: A full monitoring stack needs Prometheus (scraping), node_exporter (host metrics), cAdvisor (Docker), and Grafana (visualization). That’s four components, each with its own configuration. Total RAM: 500MB-1GB+ depending on cardinality. Setup time: 2-8 hours for a working dashboard. Modern Grafana setups increasingly use a single collector (Grafana Alloy) instead of node_exporter + cAdvisor + Promtail separately. It simplifies collection but still needs Prometheus + Grafana to be useful.

Grafana Cloud: Starts free with 10,000 active metrics series. A single server with Docker can generate 5,000+ series. Monitor 3 servers and you’re into the paid tier at $8 per 1,000 series, easily $120/mo for 5 Docker hosts.

Netdata vs Prometheus: These come up together a lot, and they sit at opposite ends. Netdata is a batteries-included, local-first agent that shows 1-second-resolution metrics immediately with no query language to learn. Prometheus is a pull-based system that scrapes metrics on an interval (commonly 15 seconds), stores them, and exposes PromQL, but it needs Grafana to visualize anything. In one 2026 benchmark, Netdata used about 35% less CPU than Prometheus (4.93 vs 7.56 cores), and a 15-second scrape interval can miss short spikes that Netdata catches. Choose Netdata for instant visibility, Prometheus for long-term, queryable, customizable observability.

When it makes sense: If you need custom dashboards, PromQL queries, alerts routed to PagerDuty, or metrics from 15 different data sources in one view, Grafana is the right choice. For everyone else, it’s overkill.

Best for: Production infrastructure teams, SREs, and anyone who considers PromQL a feature rather than a barrier. Compare Beszel vs Grafana Cloud for a self-hosted-vs-hosted cost breakdown.

Proxmox Pulse: The Proxmox Specialist

Pulse is a real-time monitoring dashboard that started as a Proxmox VE specialist. If you run Proxmox, it gives you instant visibility into nodes, VMs, and LXC containers that Proxmox’s built-in tools don’t surface well.

What makes it different: WebSocket-based updates give near-instant feedback with no polling delays, and it auto-discovers all your VMs and containers. The core is free and open source (MIT). A paid Pulse Pro tier adds AI root-cause analysis (Pulse Patrol) and Auto-Fix safe-remediation, plus RBAC, audit logging, and longer history. Check pulserelay.pro for current pricing rather than trusting any flat monthly figure you see quoted elsewhere.

The scope: Pulse is Proxmox-first, but as of 2026 it also monitors Docker and Kubernetes (plus Proxmox Backup Server and Mail Gateway), so it is no longer Proxmox-only. Where it still shines is per-node, per-VM, and per-LXC Proxmox visibility through the Proxmox API, which is auto-discovery Beszel does not do.

Beszel and LXC: This is a common point of confusion. Beszel can run on a Proxmox host or inside an LXC guest and report that machine’s CPU, memory, disk, and Docker stats, but it does not enumerate your Proxmox VMs and LXC guests through the API the way Pulse does, and an agent inside an LXC tends to show host-level stats unless you use the binary install. So for per-VM and per-LXC Proxmox visibility, use Pulse, and use Beszel for your non-Proxmox boxes. On a pure Docker VPS or Raspberry Pi, Beszel is still the lighter pick.

Best for: Proxmox environments where you want deeper VM/LXC visibility than Beszel or Netdata provide. Compare Beszel vs Pulse for the full split.

Glances: The Terminal Power Tool

Glances is a cross-platform system monitoring tool written in Python. It runs in the terminal and shows CPU, memory, disk, network, processes, and sensor data in a single view.

What makes it different: Glances goes deeper than most tools on per-process metrics. See exactly which process is eating CPU or memory, sorted in real-time. It also reads hardware sensors (temperature, fan speed, voltage) that Beszel and Dozzle don’t touch.

The trade-off: Glances is terminal-first. There’s a web UI mode (glances -w), but it’s basic. No multi-server dashboard, no built-in historical data (needs InfluxDB export), and 50-100MB RAM, not heavy, but 5x more than Beszel. For a pure interactive terminal view, btop is the modern htop (a few MB, run on demand), but unlike Glances it has no web UI, REST API, or remote multi-server mode, which is why Glances earns the always-available slot here.

Best for: SSH-heavy workflows where you want a quick htop replacement with more data. Pairs well with Beszel for always-on monitoring while Glances handles ad-hoc debugging. Compare Beszel vs Glances for web dashboard vs terminal.

Uptime Kuma: The Availability Monitor

Uptime Kuma (now on its 2.x line) solves a different problem than the tools above: it monitors whether your services are reachable. HTTP, TCP, DNS, ping, Docker, gRPC, MQTT, if it has an endpoint, Uptime Kuma can monitor it.

Why it’s essential: Server metrics tools like Beszel tell you how your servers are performing. Uptime Kuma tells you if your services are accessible. A server at 10% CPU is meaningless if your website is returning 502s because of a misconfigured proxy.

The feature set: 90+ notification channels, built-in status pages, maintenance windows, SSL certificate monitoring, and check intervals down to 20 seconds. All for ~30-50MB of RAM (closer to 60-80MB once you are running 20-30 monitors).

Beszel vs Uptime Kuma: which do you need?

This is the question people ask most, so here is the head-to-head before the verdict. Beszel and Uptime Kuma do not overlap. Beszel watches resources from inside the server; Uptime Kuma watches availability from outside.

BeszelUptime Kuma
Answers”Is my server healthy?""Is my service reachable?”
MonitorsCPU, memory, disk, network, Docker statsHTTP, TCP, DNS, ping, SSL, gRPC, MQTT
PerspectiveInternal resource metricsExternal checks
Status pagesNoYes (built-in, customizable)
AlertingThreshold alerts (email, webhook)90+ notification channels
RAM~10-15MB per agent~30-50MB (60-80MB at 20-30 monitors)
Best forCatching overload before a crashKnowing the instant a service goes down

The right answer for most self-hosters is to run both: Beszel tells you a server is about to fall over, Uptime Kuma tells you the moment something actually went down. Combined they sit around 40-65MB of RAM and cost $6/mo on InstaPods ($3/mo each). For the full breakdown, see Beszel vs Uptime Kuma.

Gatus: the config-as-code alternative

If you prefer version-controlled, GitOps-style monitoring over a clicky UI, Gatus is the lightweight counterpart to Uptime Kuma. Where Uptime Kuma stores its config in SQLite, Gatus defines every health check (HTTP, TCP, ICMP, DNS, SSH, TLS) in a single declarative YAML file you keep in Git, then renders a status page from it. It is a single Go binary (Apache-2.0, ~10-40MB, lighter than Uptime Kuma’s Node app). Choose Gatus when you want reproducible config in version control; choose Uptime Kuma when you want a point-and-click UI, 90+ notification integrations, and per-monitor history without editing YAML. Both answer “is my service reachable” and both pair cleanly with Beszel for the resource side.

Best for: Anyone who needs to know when their website, API, or service goes down. Deploy Uptime Kuma on InstaPods for $3/mo.

Monitoring Stack Combinations: Lightweight, Homelab, Proxmox, and Enterprise

Most self-hosters don’t need just one tool. Here are the most effective combinations:

The Lightweight Stack (< 20MB RAM): Beszel + Dozzle. Server metrics + Docker logs. Covers 90% of monitoring needs for homelabs and small VPS fleets. Total cost: $3/mo on InstaPods.

The Complete Stack (< 80MB RAM): Beszel + Dozzle + Uptime Kuma. Add endpoint availability monitoring and status pages. Know when something breaks AND why. Total cost: $6/mo on InstaPods.

The Proxmox Stack: Beszel + Proxmox Pulse. Beszel for Docker hosts and general servers. Pulse for VM-level and LXC Proxmox visibility. Best of both worlds.

The Enterprise Stack (500MB+ RAM): Prometheus + Grafana for custom metrics and PromQL. Only if you need custom dashboards, multi-datasource views, or complex alerting rules.

Two things round out any of these stacks. For cron and backup jobs, a dead-man’s-switch like the self-hosted Healthchecks.io covers the “did my nightly backup actually run?” gap that metrics and uptime tools both miss: jobs ping a URL on success, and you get alerted when a ping goes missing. And to actually get pinged, route every tool’s alerts through a lightweight notification server like ntfy (~20MB, HTTP-native, with iOS and UnifiedPush apps) or Gotify, instead of wiring each tool to email separately.

Which Server Monitoring Tool Should You Choose?

Here’s the decision tree:

Those are the best server monitoring tools for 1-20 servers in 2026. For most self-hosters, start with Beszel and add only what you outgrow it for.

Resource Usage Comparison

Server monitoring tools compared: RAM, resolution, setup time, license, and best use case.
ToolRAMResolutionSetupLicenseBest for
Beszel~10-15MB agent1 minute5 minMITLightweight metrics for 1-20 servers
Netdata200-500MB1 second15 minGPL-3.0+Deep, one-second observability
Dozzle~10MBReal-time (logs)2 minMITReading Docker container logs
cAdvisor~50-150MBScrape interval10 minApache-2.0Queryable container metrics in Prometheus
Glances50-100MBReal-time2 minLGPL-3.0Terminal / ad-hoc process debugging
Uptime Kuma30-50MB20s-5min5 minMITEndpoint uptime + status pages
Gatus~10-40MBConfig-defined5 min (YAML)Apache-2.0Config-as-code status pages
Grafana + Prometheus500MB-1GB+15 seconds2-8 hoursAGPL/ApacheCustom dashboards + PromQL
Proxmox Pulse~50MBReal-time (WebSocket)5 minMITPer-VM/LXC Proxmox visibility
Checkmk (Raw)~1-2GB (server)Agent-based30+ minGPLv2Large mixed fleets you outgrow lightweight tools for

Every tool above is self-hosted and open source, so your monitoring data stays on a machine you control (Netdata Cloud and Grafana Cloud send data to a SaaS only in their hosted modes). Checkmk anchors the heavy end: capable, with auto-discovery and a big plugin catalog, but its server wants ~1-2GB of RAM, well past this guide’s 1-20-server audience (Beszel vs Checkmk breaks down where the line is). Zabbix sits in the same enterprise tier - SNMP, network discovery, distributed proxies - and runs as a full server + database + web frontend, so Beszel vs Zabbix is the comparison to read if you only need server and Docker metrics.

The monitoring landscape has shifted. You don’t need a 4-component stack to answer “is my server healthy.” Start lightweight, add complexity only when you need it.

Deploy Beszel on InstaPods - one click, $3/mo, monitoring in 5 minutes.

FAQ

Beszel vs Uptime Kuma: which one do I actually need?

They measure different things, so for most people the answer is both. Beszel tracks resource health (CPU, memory, disk, Docker stats) and answers “is my server healthy,” while Uptime Kuma tracks availability (HTTP, TCP, ping, SSL) and answers “is my service reachable.” A server at 10% CPU is useless information if your site is returning 502s, which is exactly the gap Uptime Kuma fills. They do not overlap, so running both at roughly 40-65MB combined is the standard small-fleet setup.

Can I run Beszel and Uptime Kuma together?

Yes, and you should. They monitor different layers and do not conflict. Beszel handles internal resource metrics and Uptime Kuma handles external availability and status pages. On InstaPods you can deploy each as a one-click app for $3/mo, so the full metrics-plus-uptime stack runs at $6/mo.

What is the most lightweight self-hosted server monitoring tool?

Beszel is the lightest always-on option, with an agent measured at roughly 10-15MB of RAM at idle. Dozzle (logs) and Gatus (availability) are similarly light single Go binaries, while Netdata uses 200-500MB and a full Grafana + Prometheus stack uses 500MB-1GB+. For a pure on-demand terminal view, btop uses only a few MB but is not a remote or multi-server monitor.

Does Beszel support custom metrics?

Not arbitrary application-defined custom metrics as of v0.18.7 (June 2026). The custom-metrics feature request (henrygd/beszel #731) is open but not shipped, and there is no PromQL-style query language. Beszel has, however, added systemd service monitoring, S.M.A.R.T. disk health, and detailed disk I/O metrics in the v0.17-v0.18 releases. If you need fully custom application metrics, pair Beszel with Prometheus and Grafana.

Can Beszel monitor Proxmox or LXC containers?

Partly. Beszel can run on a Proxmox host or inside an LXC guest and report that machine’s CPU, memory, disk, and Docker stats. It does not enumerate Proxmox VMs and LXC guests through the Proxmox API the way Pulse does, and an agent inside an LXC tends to show host-level stats unless you use the binary install. For per-VM and per-LXC Proxmox visibility, use Pulse, and use Beszel for your non-Proxmox boxes.

How is Netdata different from Prometheus?

Netdata is a batteries-included, local-first agent that shows 1-second-resolution metrics immediately with no query language to learn. Prometheus is a pull-based system that scrapes metrics on an interval (commonly 15 seconds), stores them, and exposes the PromQL query language, but it needs Grafana to visualize anything. In one 2026 benchmark, Netdata used about 35% less CPU than Prometheus, and a 15-second scrape interval can miss short spikes that Netdata catches. Choose Netdata for instant visibility, Prometheus for long-term, queryable, customizable observability.

What is cAdvisor and do I need it?

cAdvisor is Google’s open-source container-metrics daemon that reads each container’s cgroup data and exposes raw, Prometheus-scrapeable per-container CPU, memory, network, and filesystem metrics. It has no dashboard of its own, so you only need it if you want queryable container time-series inside an existing Prometheus and Grafana setup. For a simple “how are my containers doing” view, Beszel’s built-in container stats are far less work.

How much does it cost to self-host server monitoring?

The software is free and open source for every tool in this guide. The only cost is the server it runs on. On InstaPods a Beszel pod is $3/mo, and the full Beszel + Dozzle + Uptime Kuma stack is about $6/mo, versus hosted alternatives that bill per host (Datadog from around $15 per host per month, Netdata Cloud Business at $4.50 per node, Grafana Cloud at $8 per additional 1,000 metric series).

Related reading: