Checkmate

Outside checks plus a Go agent inside each server

Checkmate checks from the outside that a website, an API, a port or a DNS record is answering, and reads CPU, memory, disk and temperature from inside your machines. The inside part needs Capture, a Go agent you install on every server you want to watch. The app is written in TypeScript (Node.js and React) and keeps everything in MongoDB.

Checkmate's network probes cover much the same ground as Uptime Kuma. The difference is the machines themselves: Checkmate installs an agent that reports CPU, memory and disk, while Uptime Kuma installs nothing on the servers it watches and sticks to remote checks, SNMP included.

The comparison of self-hosted uptime monitors and status pages sets Checkmate against tools that only probe from outside.

Hardware thresholds and three ways into Docker

• Ten monitor types: HTTP with response body checks (string, regex or a JMESPath expression), ping, TCP port, DNS, gRPC, WebSocket, game servers, PageSpeed, Docker and system metrics. HTTPS monitors also watch certificate and domain expiry.
• Hardware thresholds: each hardware monitor takes its own CPU, memory, disk and temperature limits. When a reading crosses one, the monitor switches to exceeded and notifications go out.
• Three ways into Docker: since 3.12, a Docker monitor reports state, health, CPU and memory for every container on a host, through the local socket, a remote daemon over mutual TLS, or Capture.
• Status pages: a public URL lists the monitors you pick with an uptime bar per service, in one of five themes, with your logo and colour, and custom CSS since 3.9.1.
• Alerts: email, webhooks, Slack, Discord, Teams, Telegram, Matrix, Rocket.Chat, PagerDuty, Pushover, ntfy, SignalGrid and Twilio SMS, plus scheduled maintenance windows.

Needs MongoDB and an open port on each server

MongoDB is required. The reference Compose file runs two services, the app and mongo:8.0; the database is not bundled in the image. The project site puts the footprint at about 1 GB of RAM and a few GB of disk, and the README shows MongoDB using 398 MB while checking 323 servers every minute. History is kept for 90 days by default.

Redis is gone, but the docs still list it. Neither the 3.12 Compose file nor the server's dependencies mention Redis, yet the documentation's server requirements page and architecture diagram still draw it next to MongoDB.

Every monitored server has to expose a port. Capture serves a REST API on port 59232 and Checkmate polls it, using a shared secret (API_SECRET) entered on both sides. The port must be reachable from the Checkmate host. The agent speaks plain HTTP; its repository ships a Caddy setup for putting HTTPS in front. S.M.A.R.T. disk data needs the agent installed as a binary with smartmontools, since the Docker image cannot read it. Capture's latest release, 1.4.0, came out on 12 March 2026.

No on-call scheduling, no tracing. Checkmate can hand alerts to PagerDuty, but its documentation has nothing on on-call rotations or APM. OneUptime puts those next to monitoring and status pages.

Pitched against per-host billing. The project site sets Checkmate against Datadog and PagerDuty, which charge per host, and against a Prometheus, Grafana, Alertmanager and exporters stack. Its stated audience includes agencies running one status page per client and sysadmins who want hardware metrics without standing up Prometheus. The license is AGPL-3.0, so anyone offering a modified version as a network service has to publish their changes. The FAQ says there is no paid support tier.

Repackaged in July, Helm chart behind. Since 3.10.0 (28 July 2026), the app ships as a single image and the old split images no longer receive updates. According to the README, the Helm chart still deploys those old images, pinned at 3.8.1. Between 3.3 (28 January 2026) and 3.12.0 (13 September 2026), the repository shipped ten minor releases.