Healthchecks

Healthchecks is an open-source monitoring service purpose-built for detecting silent failures in cron jobs, backup scripts, data pipelines, and any scheduled task. Rather than actively probing services, it inverts the model: your jobs are expected to send an HTTP ping or email after each successful run. When a ping fails to arrive within the configured window, Healthchecks fires an alert through any of its 29 notification channels.

Built with Python 3.12+ and Django 6.0, Healthchecks supports PostgreSQL, MySQL, MariaDB, and SQLite for storage. It ships with a live-updating web dashboard, a full REST API, an SMTP listener for email-based pings, WebAuthn 2FA, team project management, and public status badges. Docker images are available, and the entire configuration is driven through environment variables.

The hosted version at healthchecks.io lets teams get started immediately, while the open-source codebase — licensed under BSD 3-Clause — enables full self-hosted deployments with identical functionality. The optional payments module can be enabled for operators who want to run their own multi-tenant instance with subscription billing.

With over 10,000 GitHub stars, 75 releases since 2017, and active development across 97 contributors, Healthchecks has matured into a production-grade solution used by DevOps teams, indie developers, and system administrators worldwide to eliminate silent failures from their automated workflows.

What You Get

• Live-Updating Dashboard - Real-time status board showing all monitored jobs color-coded as Up, Late, or Down, with tag-based filtering and per-check event logs that update without page refresh.
• Period and Grace Time Controls - Per-check configuration of the expected ping interval and a grace period before alerts fire, preventing false positives during acceptable delays in long-running jobs.
• Cron Expression and OnCalendar Scheduling - Define expected ping windows using standard five-field cron syntax or systemd-style OnCalendar expressions, parsed by the cronsim and oncalendar libraries respectively.
• 29 Notification Integrations - Send alerts to Slack, Discord, Microsoft Teams, PagerDuty, Opsgenie, Telegram, SMS, WhatsApp, Pushover, ntfy, Rocket.Chat, Matrix, Mattermost, Zulip, email, webhooks, shell commands, Apprise, and more — each in an isolated module.
• HTTP and SMTP Ping Endpoints - Accept pings via HTTP GET/POST to a UUID-based URL or via email sent to a check-specific address using the built-in aiosmtpd SMTP listener, enabling monitoring of legacy and air-gapped systems.
• Public Status Badges - Generate hard-to-guess PNG and SVG status badges per check or per tag for embedding in READMEs, internal dashboards, or public status pages without requiring authentication.
• WebAuthn 2FA Support - Enable FIDO2/WebAuthn two-factor authentication using hardware security keys or passkeys, configurable via the RP_ID environment variable.
• Team Projects and Read-Only Access - Organize checks into projects, invite team members, and assign read-only access so on-call engineers can view status without being able to modify configurations.
• Full REST API - Programmatically create, update, pause, and delete checks; list channels; retrieve ping history and flip events; and manage badges via a versioned JSON API authenticated with project API keys.
• External Authentication Support - Integrate with existing LDAP or OAuth infrastructure via an HTTP header set by an authenticating reverse proxy, with automatic account creation for first-time logins.
• Scheduled Reports and Reminders - Run the sendreports management command to dispatch daily, weekly, or monthly email summaries of job health and downtime duration across all checks in a project.
• Database and Object Storage Cleanup - Built-in management commands (pruneusers, prunetokenbucket, pruneobjects) handle automated housekeeping of expired records and orphaned objects in external S3-compatible storage.

Common Use Cases

• Nightly database backup validation - A DevOps engineer appends a curl ping to their PostgreSQL backup script; Healthchecks alerts via PagerDuty if the backup hasn’t completed by the expected time, preventing undetected backup failures.
• ETL pipeline health tracking - A data team instruments each step of their nightly data pipeline to ping Healthchecks on completion; a missing ping triggers a Slack alert before stakeholders notice missing morning reports.
• SSL certificate renewal confirmation - A sysadmin wraps certbot in a script that pings Healthchecks after successful renewal; a missed ping means the certificate renewal failed and alerts fire days before expiry.
• CI/CD pipeline monitoring - A platform team adds a ping step at the end of GitHub Actions and Jenkins pipelines; failed runs that terminate early stop the ping from arriving, triggering SMS notifications to the on-call engineer.
• Air-gapped server task monitoring - A government IT team cannot make outbound HTTP calls from secure servers, so they configure their scheduled scripts to send email pings to the Healthchecks SMTP listener running on the DMZ.
• Public status page embedding - A SaaS product team uses Healthchecks status badges on their public status page to display real-time health of their email sending queue, daily report generation, and data sync jobs without exposing authentication credentials.

Under The Hood

Architecture Healthchecks uses a layered Django application structure organized into discrete apps — accounts, api, front, integrations, lib, logs, and payments — each with clean boundaries and no cross-cutting concerns. The core monitoring logic lives in the api app: the Check model tracks state transitions and the ping views are intentionally lightweight and unauthenticated. Alerting runs as a separate management command (sendalerts) that continuously polls for state changes and dispatches notifications, keeping the HTTP surface stateless. Each of the 29 notification integrations lives in its own subdirectory under hc/integrations/ and implements a common Transport base class, making new integrations addable without touching core code. The payments module is opt-in via an environment variable, letting the same codebase serve pure OSS and commercial multi-tenant deployments.

Tech Stack Django 6.0 on Python 3.12+ forms the backbone, with psycopg and mysqlclient enabling support for PostgreSQL, MySQL, MariaDB, and SQLite. Pydantic handles API request validation with field-level constraints and model validators. The cronsim library parses standard cron expressions and the oncalendar library handles systemd-style OnCalendar schedules. aiosmtpd powers the SMTP listener for email-based pings. fido2 implements WebAuthn/FIDO2 two-factor authentication. whitenoise serves static assets directly from Django in production. uWSGI and Docker with multi-stage builds cover the production deployment path. The CI matrix tests across SQLite, PostgreSQL, MySQL, and MariaDB on Python 3.12, 3.13, and 3.14 simultaneously.

Code Quality The test suite spans nearly 200 test files with individual test modules per API endpoint, per management command, and per integration transport. The time-machine library enables deterministic datetime testing without monkey-patching. mypy with django-stubs-ext and mypy_django_plugin enforces type safety at the ORM query level — a level of rigor rarely seen in Django projects. The configuration layer uses typed accessor functions (envbool, envint, envsecret) including _FILE suffix support for secret injection from the filesystem. Error handling in transport modules uses explicit exception hierarchies with structured logging. A separate coverage CI workflow tracks test completeness alongside the main test matrix.

What Makes It Unique The inverted monitoring model — jobs report success rather than being polled for liveness — is the right abstraction for scheduled task monitoring and Healthchecks executes it with exceptional depth. Supporting systemd OnCalendar expressions alongside standard cron syntax covers infrastructure-native scheduling that most competitors ignore. The _FILE environment variable convention for secret injection is a thoughtful Kubernetes and Docker secrets pattern baked into the configuration layer. Having 29 notification integrations each in isolated modules with their own test suites is unusually thorough. The optional payments module lets operators run an identical-feature commercial hosted service from the same open-source codebase — a genuinely transparent business model.

Self-Hosting

Healthchecks is released under the BSD 3-Clause license, one of the most permissive open-source licenses available. You can use it commercially, modify it freely, distribute modified versions, and integrate it into proprietary infrastructure without any copyleft obligations. The only requirement is preserving the copyright notice and license text in redistributions. There are no open-core restrictions, no gated enterprise features, and no license keys — the self-hosted version and the hosted healthchecks.io service run from the same codebase.

Running Healthchecks yourself requires a Python 3.12+ environment, a supported relational database (PostgreSQL is recommended for production; MySQL, MariaDB, and SQLite also work), and an SMTP relay for outbound email. In practice, most teams deploy via the official Docker image, which bundles uWSGI and can be configured entirely through environment variables. You are responsible for database backups, SSL termination via a reverse proxy, keeping the application updated across releases, and running the sendalerts and sendreports management commands as persistent background processes — typically managed by systemd, supervisor, or Docker Compose restart policies. If you use email pings via the SMTP listener, you will also need to expose a port and manage inbound mail routing.

The hosted service at healthchecks.io removes all operational overhead: it provides a managed database, automatic updates, guaranteed uptime SLAs, and support. The free tier covers up to 20 checks; paid plans extend check counts, team seats, and log retention. Self-hosters give up managed upgrades across the active release cadence (roughly monthly releases), the support relationship, and guaranteed infrastructure reliability in exchange for full data sovereignty and no per-check or per-seat pricing. For teams with modest infrastructure skills and a need for unlimited checks or custom integrations, self-hosting is straightforward and well-documented.