Hertzbeat

Last reviewed Sep 13, 2026 · 864 words

Hertzbeat sits in the gap between Uptime Kuma and Zabbix: agentless like the first, able to pull real metrics out of MySQL, PostgreSQL, Redis, JVMs, SNMP switches, and Linux hosts over SSH like the second. Whether that gap is worth 1 GB of JVM to you is the question. If your monitoring need is "tell me when a service is down", it is not, and Uptime Kuma on 100 MB remains the right answer. If you have been writing SSH scripts to graph a database's connection count because you did not want to run Zabbix, Hertzbeat is the tool that was built for you.

Agentless means credentials, not installs

Every monitor in Hertzbeat is a template: a YAML document that says which protocol to use (HTTP, JDBC, SSH, SNMP, JMX, Redis, and more), what to query, and how to map the response into metrics. The server connects out to the target with credentials you supply, so monitoring a MySQL instance means creating a read-only database user and typing its password into Hertzbeat, and monitoring a Linux host means an SSH key. Nothing is installed on the target. That is the trade compared with agent-based systems: less to deploy, but the monitoring server holds a credential for everything it watches, which is a reason to keep it inside the network and put it behind SSO. The catalogue of built-in templates is large and covers the common self-hosted stack, and the YAML is readable enough that adapting one for a service it does not know takes an hour, not a day.

The JVM cost is real and the defaults hide the history problem

The image is apache/hertzbeat, the UI is on port 1157, and the default login is admin with password hertzbeat, which you change on the first day.

services:
  hertzbeat:
    image: apache/hertzbeat:latest
    ports:
      - "1157:1157"
    volumes:
      - ./data:/opt/hertzbeat/data
      - ./logs:/opt/hertzbeat/logs
    restart: unless-stopped

Out of the box it uses an embedded H2 database for configuration and, unless you configure a time-series store, it keeps only recent metric values in memory. That is the first-week surprise: charts that look fine on day one and show no history on day 8. For durable metrics, point it at VictoriaMetrics (or IoTDB or TDengine) in the application config, and move the configuration database to MySQL or PostgreSQL if the instance will monitor more than a few dozen targets. With VictoriaMetrics beside it, plan on 1.5 GB for Hertzbeat itself under moderate load; the 1 GB figure is an idle JVM, not a working one.

Alerting is threshold rules plus a lot of notifiers

Alert rules are expressions over the collected metrics, such as available disk below 10% or response time above 2,000 ms for 3 consecutive checks, with severity levels and silence windows. Notifications go out over email, webhooks, Telegram, Discord, Slack, and a long list of Chinese chat platforms, reflecting where much of the user base is. Webhook support means it slots into whatever you already use; a webhook to ntfy or Gotify is the standard homelab pattern. There is also a public status page feature, which is handy but less polished than dedicated tools.

Newer project, Apache home, and what that implies

Hertzbeat started in 2022 and moved into the Apache Software Foundation as an incubating project, which is a meaningful signal about governance, licensing (Apache-2.0), and the chance of it surviving its original authors losing interest. It also means the documentation is bilingual and occasionally reads as translated, and community answers are often in Chinese first. At 7,384 stars it is smaller than Uptime Kuma by a wide margin and smaller than Zabbix in every dimension except ease. Expect rough edges in the UI, expect templates to need tweaking for unusual versions of a service, and expect fast releases. It is a reasonable bet; it is not yet a boring one.

Where the bigger projects are the safer choice

Uptime checks only: Uptime Kuma or Gatus, both lighter and more mature, and the homelab monitoring and uptime piece explains the split between the two. Deep host metrics and a decade of stability: Zabbix, at the price of agents and a steeper setup. Metrics as a first-class data model with alerting you can version-control: Prometheus and Grafana, at the price of running exporters on every target. Hertzbeat wins the narrow case of wanting database, middleware, and network-device metrics without installing anything on those systems and without learning PromQL. The monitoring category covers the whole field.

What I'd do

If you run more than 3 databases or any SNMP gear and nothing currently graphs them, deploy Hertzbeat with VictoriaMetrics from the first day, give the pair 2 GB, change the default password, and keep it on the LAN behind your proxy's auth. Use it alongside Uptime Kuma rather than instead of it, since Kuma's public status page and notification history are still better. If your monitoring need is a list of green and red dots, skip Hertzbeat entirely and keep the 1 GB.