Healthchecks

What Healthchecks does

Healthchecks watches for things that should happen and do not. Instead of probing a server, it hands each job a unique URL. Your backup script, cron job or systemd timer calls that URL when it finishes, and Healthchecks stays silent as long as the calls (“pings”) arrive on schedule. When one is late beyond a configurable grace time, the check goes down and alerts go out. The technique is known as a dead man’s switch, and it catches failures that uptime monitors miss: a cron daemon that stopped, a backup that silently never ran, a queue worker that hung.

Schedules can be a simple period (every hour, every day), a cron expression with the server’s time zone, or one or more systemd OnCalendar expressions, so Healthchecks checks that a job ran at the right time and not just at roughly the right interval. A job can also send a start signal, which lets Healthchecks measure run time and alert when a job starts but never finishes, and a failure signal or exit code to report errors straight away. The body of a ping, such as the last lines of a script’s output, is kept in the check’s log. Jobs that cannot make HTTP requests can send an email instead, handled by a built-in SMTP listener.

The documentation is clear about scope: Healthchecks is not meant for probing website uptime, collecting performance metrics or aggregating logs.

Alerts and integrations

The project ships more than 25 notification channels. Among them are email, webhooks, Slack, Mattermost, Discord, Microsoft Teams, Telegram, Signal, Matrix, ntfy, Gotify, Pushover, PagerDuty and Opsgenie, as well as Apprise and local shell commands. Checks are grouped into projects that can be shared with team members, including read-only access. Monthly email reports summarize each project, and optional reminders repeat while something stays down. Status badges with hard-to-guess public URLs can go in READMEs or dashboards, and each project exposes a Prometheus endpoint with metrics such as whether every check is up or running. A Management API creates and updates checks from code.

Self-hosting Healthchecks

Healthchecks is a Django application needing Python 3.12 or later and PostgreSQL, MySQL or MariaDB; SQLite is used only in the development setup. The repository includes a reference Dockerfile and a Docker Compose example, and prebuilt images exist for amd64, arm/v7 and arm64. As a minimum you configure the site URL, a secret key and an SMTP server, because Healthchecks sends login links and alerts by email.

Two details matter in production. Alerts are sent by a separate sendalerts process that must run all the time; if it stops, nothing is sent. And the README insists on a reverse proxy that sets the X-Forwarded-For header, since rate limiting relies on it. By default each check keeps its 100 most recent pings, which an administrator can raise per user. Login through LDAP or OAuth is possible by trusting a header set by an authenticating proxy. Some integrations, such as the Slack app flow, Telegram and Signal, need extra setup on a self-hosted instance.

Hosted version

healthchecks.io runs the same open source code as a hosted service, with a free Hobbyist plan limited by the number of jobs and paid plans with higher limits and SMS or phone-call credits. Open source projects and non-profits can get the Business plan without charge. The service is run by the author’s small company in Latvia on Hetzner servers, and its about page is candid that availability is best effort with a one-person operations team.

Limitations

Healthchecks does one thing. It does not check whether a website or port responds, has no status page beyond badges, and collects no metrics or logs. Self-hosting is simple but not a single container: you need a database, an SMTP server and the background processes running reliably, and you should watch the instance itself.

Who it suits

Healthchecks suits anyone with backups, cron jobs or scheduled pipelines whose silent failure would hurt. It pairs naturally with a probe-based tool such as Uptime Kuma or Gatus, which cover the “is it reachable” side; the monitoring guide explains how the pieces fit.