Open source uptime and monitoring tools

Four different jobs

Monitoring tools cover four related but separate tasks, and it pays to know which one you need before you compare products.

• Uptime checks and status pages. A scheduler sends requests to URLs, ports, DNS records or other endpoints, records response times and alerts you when something fails. Most of these tools also publish a public status page. Uptime Kuma and Checkmate are configured in a web interface, Gatus and openstatus can be managed as code, and Upptime runs entirely on GitHub Actions and GitHub Pages, with no server of your own.
• Heartbeat monitoring. For cron jobs, backups and other scheduled tasks, the job reports in each time it runs and the monitor alerts you when a report does not arrive on time. Healthchecks is built for this.
• Infrastructure and metrics monitoring. Time series from hosts, containers, databases and network devices, with alert rules and dashboards. Prometheus collects and stores metrics and evaluates alerts, Grafana visualizes and alerts on data stored elsewhere, Zabbix is a complete agent-based system with SNMP and other agentless checks, and Netdata collects per-second metrics on each node with almost no setup.
• Observability and APM. Traces, logs and metrics from applications in one place, used to follow a slow request across services. SigNoz, OpenObserve and Coroot focus on this, and OneUptime combines it with uptime checks, status pages, incidents and on-call scheduling.

Prometheus and Grafana are building blocks, not finished products. A typical stack combines Prometheus, exporters, Alertmanager and Grafana, and you assemble and maintain those parts yourself.

Where your checks run from

An uptime monitor only sees the network path from where it runs. A self-hosted Uptime Kuma, Gatus or Checkmate instance on the same server or in the same data center as your site will go down with it, and it cannot tell you that visitors in another region cannot reach you. Put the monitor on separate infrastructure, or use a tool that checks from several places: the openstatus hosted service checks from many public regions, while a self-hosted openstatus only uses private probes that you deploy; OneUptime lets you run your own probes; Upptime’s checks run on GitHub’s runners.

Open standards and lock-in

Two standards decide how hard it is to change tools later. OpenTelemetry, a Cloud Native Computing Foundation project, defines vendor-neutral APIs, SDKs and a collector for generating and sending traces, metrics and logs; it deliberately leaves storage and visualization to other tools. The Prometheus exposition format, formalized as OpenMetrics, is the common text format for exposing metrics. SigNoz, OpenObserve and OneUptime accept OpenTelemetry data, and Datadog and New Relic both document OpenTelemetry ingestion too. If you instrument with OpenTelemetry rather than a vendor’s own agent, moving between backends is mostly a matter of pointing the collector somewhere else.

What to check before you choose

1. The job. Uptime checks, cron heartbeats, infrastructure metrics or application traces. Several tools here do one of these well; few do all of them.
2. Self-hosting effort. Uptime Kuma runs as one container with SQLite and Prometheus is a single binary, while SigNoz and OneUptime need ClickHouse, and the OneUptime docs recommend 16 GB of RAM for a production Docker Compose install. Each app page lists the documented requirements.
3. Retention and storage. Telemetry grows fast. Check whether data sits on local disk or object storage, whether the tool can scale past one node, and how retention is set.
4. Alerting. Notification channels, escalation, on-call schedules, and grouping so one outage does not send a hundred messages.
5. Configuration as code. Gatus and openstatus are defined in YAML (openstatus also with Terraform), which makes checks easy to review and version.
6. License. Several projects are open core. SigNoz and OneUptime keep enterprise code in proprietary ee/ directories, OpenObserve and Coroot sell separate enterprise editions, and Netdata’s dashboard UI is closed source even though its agent is GPL. The app pages explain what each open source edition includes.

Source-available projects not listed

Some well-known projects are not open source under the OSI definition, so they are not listed here. Graylog, a log management platform, is released under the Server Side Public License. Sentry, which includes uptime and cron monitors next to error tracking, uses the Functional Source License, under which each version becomes Apache-2.0 only after two years. Both licenses place conditions on offering the software as a service or in a competing product, and neither is an OSI-approved license.