Checkmk

Last reviewed Sep 13, 2026 · 868 words

Point Checkmk at a Linux host with its agent installed and it will discover somewhere between 80 and 150 individual services on that machine in under a minute: every filesystem, every network interface, every systemd unit, the RAID state, the NTP drift, the temperature sensors. That auto-discovery is why IT teams have run it since 2009 and why the free Raw Edition is worth the 1 GB of RAM it wants. The catch is that Checkmk thinks in a vocabulary of hosts, services, folders, and rules that takes a weekend to internalise, and the vendor keeps a real list of features behind the paid editions.

Raw versus Enterprise is the first fork in the road

The GPL-2.0 Raw Edition on GitHub (2,363 stars) is the complete monitoring core, the web UI, the agents, and about 2,000 check plugins. What it does not have: the faster Enterprise monitoring core (Raw runs on Nagios core underneath), the agent bakery that builds custom agent packages per host, reporting, the push-based cloud agents, and some dashboarding polish. For up to a few hundred hosts, the Nagios core is fine. The agent bakery is the one I miss, because it means installing and configuring agents by hand or with your own Ansible.

The free tier of the Cloud Edition covers 750 services, which is roughly 5 to 8 servers worth. Above that the price is per service, and it adds up faster than you expect once discovery finds 120 services on a single box.

One container, one site

Checkmk uses a concept called OMD sites: independent instances, each with its own Apache, core, and data directory. In Docker the image creates one site for you:

docker run -d --name checkmk \
  -p 8080:5000 -p 8000:8000 \
  --tmpfs /opt/omd/sites/cmk/tmp:uid=1000,gid=1000 \
  -v checkmk-data:/omd/sites \
  --restart always \
  checkmk/check-mk-raw:latest

The admin password is printed in the container logs on first start, and the UI is at http://host:8080/cmk/. Port 8000 carries agent registration traffic. On bare metal you install the .deb or .rpm, run omd create monitoring, then omd start monitoring. Either way, budget 1 GB of RAM for a site watching 10 hosts, and expect that to roughly double at 50.

Agents plus SNMP cover almost everything

The Linux and Windows agents are small scripts and binaries that listen on TCP 6556 and dump plain text when the server connects. Modern agents register with the site over TLS using cmk-agent-ctl register, so the transport is encrypted and the agent only answers its own server. For switches, printers, and UPS units, SNMP walks give you the same discovered-service treatment. Docker hosts get container-level checks through the agent's Docker plugin, which is how I keep an eye on 30 containers without a per-container exporter.

Once a host is added, "Run service discovery" lists what it found, you accept the lot or a subset, then "Activate changes" pushes the config live. That two-step activate model is the concept that trips people up in the first hour: nothing you edit in Setup takes effect until you activate.

Rules replace per-host configuration

Instead of setting a disk threshold on each host, you write a rule: filesystems on hosts in the production folder warn at 85 percent and go critical at 95, except on hosts tagged backup-target, where 98 is fine. Rules stack, most specific wins, and the same mechanism governs notification routing, check intervals, and which contacts get paged. This is where Checkmk scales well and where it costs you the learning time. A 5-host homelab may never need more than 10 rules; a 200-host estate lives entirely in them.

Notifications go out through email, Slack, PagerDuty, Opsgenie, and a scripted handler you can write yourself, with time-period and escalation logic that Uptime Kuma does not attempt. The broader options are laid out in the homelab monitoring and uptime piece.

Where Zabbix or something smaller wins

Zabbix is the closest peer in the monitoring category: fully free with no gated edition, similar reach, and a stronger story for templated network devices at scale. It has a harder initial learning curve and weaker auto-discovery, so my split is Zabbix for people who resent paid editions on principle, Checkmk for people who want the first day to be productive. For 3 to 10 services and a status page, Uptime Kuma in 100 MB of RAM is the right tool, and Checkmk would be a hammer looking for a nail.

What I'd do

Deploy Raw Edition in Docker, install the agent on every Linux box with the TLS registration step, accept the discovered services, and write five rules: disk thresholds, a notification rule for one Slack channel, quiet hours for the lab, a longer check interval for the NAS, and an exclusion for the ephemeral Docker networks that come and go. Ignore the Enterprise features until you have more than 50 hosts, and if you find yourself wanting them, price it honestly against a weekend of Zabbix.