|Project Name||Stars||Downloads||Repos Using This||Packages Using This||Most Recent Commit||Total Releases||Latest Release||Open Issues||License||Language|
|Sentry||35,211||2||2 hours ago||7||November 04, 2016||1,672||other||Python|
|Developer-first error tracking and performance monitoring|
|Healthchecks||6,617||a day ago||63||bsd-3-clause||Python|
|Open-source cron job and background task monitoring service, written in Python & Django|
|Self-hosted, easily-deployable monitoring and alerts service - like a lightweight PagerDuty|
|Shynet||2,557||4 days ago||40||apache-2.0||Python|
|Modern, privacy-friendly, and detailed web analytics that works without cookies or JS.|
|Tacticalrmm||1,919||8 hours ago||143||August 18, 2023||247||other||Python|
|A remote monitoring & management tool, built with Django, Vue and Go.|
|Django Prometheus||1,271||56||24||24 days ago||104||December 19, 2021||70||apache-2.0||Python|
|Export Django monitoring metrics for Prometheus.io|
|Django Health Check||1,056||69||21||a day ago||71||September 05, 2022||49||mit||Python|
|a pluggable app that runs a full check on the deployment, using a number of plugins to check e.g. database, queue server, celery processes, etc.|
|Promgen||1,009||4 days ago||2||February 02, 2018||33||mit||Python|
|Promgen is a configuration file generator for Prometheus|
|Watcher||738||17 days ago||12||agpl-3.0||Python|
|Watcher - Open Source Cybersecurity Threat Hunting Platform. Developed with Django & React JS.|
|Django Watchman||492||20||1||17 days ago||48||March 04, 2022||21||bsd-3-clause||Python|
|django-watchman exposes a status endpoint for your backing services like databases, caches, etc.|
Healthchecks is a cron job monitoring service. It listens for HTTP requests and email messages ("pings") from your cron jobs and scheduled tasks ("checks"). When a ping does not arrive on time, Healthchecks sends out alerts.
Healthchecks comes with a web dashboard, API, 25+ integrations for delivering notifications, monthly email reports, WebAuthn 2FA support, team management features: projects, team members, read-only access.
The building blocks are:
Healthchecks is licensed under the BSD 3-clause license.
Healthchecks is available as a hosted service at https://healthchecks.io/.
The "My Checks" screen. Shows the status of all your cron jobs in a live-updating dashboard.
Each check has configurable Period and Grace Time parameters. Period is the expected time between pings. Grace Time specifies how long to wait before sending out alerts when a job is running late.
Alternatively, you can define the expected schedules using a cron expressions. Healthchecks uses the cronsim library to parse and evaluate cron expressions.
Check details page, with a live-updating event log.
Healthchecks provides status badges with public but hard-to-guess URLs. You can use them in your READMEs, dashboards, or status pages.
To set up Healthchecks development environment:
Install dependencies (Debian/Ubuntu):
sudo apt update sudo apt install -y gcc python3-dev python3-venv libpq-dev libcurl4-openssl-dev libssl-dev
Prepare directory for project code and virtualenv. Feel free to use a different location:
mkdir -p ~/webapps cd ~/webapps
Prepare virtual environment (with virtualenv you get pip, we'll use it soon to install requirements):
python3 -m venv hc-venv source hc-venv/bin/activate pip3 install wheel # make sure wheel is installed in the venv
Check out project code:
git clone https://github.com/healthchecks/healthchecks.git
Install requirements (Django, ...) into virtualenv:
pip install -r healthchecks/requirements.txt
macOS only - pycurl needs to be reinstalled using the following method (assumes OpenSSL was installed using brew):
export PYCURL_VERSION=`cat requirements.txt | grep pycurl | cut -d '=' -f3` export OPENSSL_LOCATION=`brew --prefix openssl` export PYCURL_SSL_LIBRARY=openssl export LDFLAGS=-L$OPENSSL_LOCATION/lib export CPPFLAGS=-I$OPENSSL_LOCATION/include pip uninstall -y pycurl pip install pycurl==$PYCURL_VERSION --compile --no-cache-dir
Create database tables and a superuser account:
cd ~/webapps/healthchecks ./manage.py migrate ./manage.py createsuperuser
With the default configuration, Healthchecks stores data in a SQLite file
hc.sqlite in the checkout directory (
Run development server:
The site should now be running at
To access Django administration site, log in as a superuser, then
Healthchecks reads configuration from environment variables.
Healthchecks comes with Django's administration panel where you can manually view and modify user accounts, projects, checks, integrations etc. To access it,
Healthchecks must be able to send email messages, so it can send out login links and alerts to users. Specify your SMTP credentials using the following environment variables:
Implicit TLS (recommended):
DEFAULT_FROM_EMAIL = "[email protected]" EMAIL_HOST = "your-smtp-server-here.com" EMAIL_PORT = 465 EMAIL_HOST_USER = "smtp-username" EMAIL_HOST_PASSWORD = "smtp-password" EMAIL_USE_TLS = False EMAIL_USE_SSL = True
Port 465 should be the preferred method according to RFC8314 Section 3.3: Implicit TLS for SMTP Submission. Be sure to use a TLS certificate and not an SSL one.
DEFAULT_FROM_EMAIL = "[email protected]" EMAIL_HOST = "your-smtp-server-here.com" EMAIL_PORT = 587 EMAIL_HOST_USER = "smtp-username" EMAIL_HOST_PASSWORD = "smtp-password" EMAIL_USE_TLS = True
For more information, have a look at Django documentation, Sending Email section.
Healthchecks comes with a
smtpd management command, which starts up a
SMTP listener service. With the command running, you can ping your
checks by sending email messages
[email protected] email addresses.
Start the SMTP listener on port 2525:
./manage.py smtpd --port 2525
Send a test email:
curl --url 'smtp://127.0.0.1:2525' \ --mail-from '[email protected]' \ --mail-rcpt '11111111-1111[email protected]' \ -F '='
Healthchecks comes with a
sendalerts management command, which continuously
polls database for any checks changing state, and sends out notifications as
needed. Within an activated virtualenv, you can manually run
sendalerts command like so:
In a production setup, you will want to run this command from a process manager like systemd or supervisor.
Healthchecks also comes with a
sendreports management command which
sends out monthly reports, weekly reports, and the daily or hourly reminders.
sendreports without arguments to run any due reports and reminders
and then exit:
Run it with the
--loop argument to make it run continuously:
./manage.py sendreports --loop
Healthchecks deletes old entries from
tables automatically. By default, Healthchecks keeps the 100 most recent
pings for every check. You can set the limit higher to keep a longer history:
go to the Administration Panel, look up user's Profile and modify its
"Ping log limit" field.
For each check, Healthchecks removes notifications that are older than the oldest stored ping for same check.
Healthchecks also provides management commands for cleaning up
Remove user accounts that match either of these conditions:
Remove old records from the
api_tokenbucket table. The TokenBucket
model is used for rate-limiting login attempts and similar operations.
Any records older than one day can be safely removed.
Remove old records from the
api_flip table. The Flip
objects are used to track status changes of checks, and to calculate
downtime statistics month by month. Flip objects from more than 3 months
ago are not used and can be safely removed.
Remove old objects from external object storage. When an user removes
a check, removes a project, or closes their account, Healthchecks
does not remove the associated objects from the external object
storage on the fly. Instead, you should run
(for example, once a month). This command first takes an inventory
of all checks in the database, and then iterates over top-level
keys in the object storage bucket, and deletes any that don't also
exist in the database.
When you first try these commands on your data, it is a good idea to test them on a copy of your database, not on the live database right away. In a production setup, you should also have regular, automated database backups set up.
Healthchecks optionally supports two-factor authentication using the WebAuthn
standard. To enable WebAuthn support, set the
RP_ID (relying party identifier )
setting to a non-null value. Set its value to your site's domain without scheme
and without port. For example, if your site runs on
Note that WebAuthn requires HTTPS, even if running on localhost. To test WebAuthn
locally with a self-signed certificate, you can use the
Healthchecks supports external authentication by means of HTTP headers set by reverse proxies or the WSGI server. This allows you to integrate it into your existing authentication system (e.g., LDAP or OAuth) via an authenticating proxy. When this option is enabled, healthchecks will trust the header's value implicitly, so it is very important to ensure that attackers cannot set the value themselves (and thus impersonate any user). How to do this varies by your chosen proxy, but generally involves configuring it to strip out headers that normalize to the same name as the chosen identity header.
To enable this feature, set the
REMOTE_USER_HEADER value to a header you wish to
authenticate with. HTTP headers will be prefixed with
HTTP_ and have any dashes
converted to underscores. Headers without that prefix can be set by the WSGI server
itself only, which is more secure.
REMOTE_USER_HEADER is set, Healthchecks will:
Healthchecks can optionally store large ping bodies in S3-compatible object storage. To enable this feature, you will need to:
ensure you have the MinIO Python library installed:
pip install minio
configure the credentials for accessing object storage:
Healthchecks will use external object storage for storing any request bodies that exceed 100 bytes. If the size of a request body is 100 bytes or below, Healthchecks will still store it in the database.
Healthchecks automatically removes old stored ping bodies from object
storage while uploading new data. However, Healthchecks does not automatically
clean up data when you delete checks, projects or entire user accounts.
pruneobjects management command to remove data for checks that don't
exist any more.
When external object storage is not enabled (the credentials for accessing object storage are not set), Healthchecks stores all ping bodies in the database. If you enable external object storage, Healthchecks will still be able to access the ping bodies already stored in the database. You don't need to migrate them to the object storage. On the other hand, if you later decide to disable external object storage, Healthchecks will not have access to the externally stored ping bodies any more. And there is currently no script or management command for migrating ping bodies from external object storage back to the database.
To enable the Slack "self-service" integration, you will need to create a "Slack App".
To do so:
Bot Token Scopeshttps://api.slack.com/apps/APP_ID/oauth?).
SITE_ROOT/integrations/add_slack_btn/. For example, if your SITE_ROOT is
https://my-hc.example.orgthen the redirect URL would be
To enable Discord integration, you will need to:
SITE_ROOT/integrations/add_discord/. For example, if you are running a development server on
localhost:8000then the redirect URI would be
Pushover integration works by creating an application on Pushover.net which is then subscribed to by Healthchecks users. The registration workflow is as follows:
To enable the Pushover integration, you will need to:
PUSHOVER_SUBSCRIPTION_URLenvironment variables. The Pushover subscription URL should look similar to
Healthchecks uses signal-cli to send Signal notifications. Healthcecks interacts with signal-cli over UNIX or TCP socket. Healthchecks requires signal-cli version 0.11.2 or later.
To enable the Signal integration via UNIX socket:
signal-cli -a +xxxxxx daemon --socket /tmp/signal-cli-socket
To enable the Signal integration via TCP socket:
signal-cli -a +xxxxxx daemon --tcp 127.0.0.1:7583
SIGNAL_CLI_SOCKETenvironment variable using "hostname:port" syntax, example:
Create a Telegram bot by talking to the BotFather. Set the bot's name, description, user picture, and add a "/start" command. To avoid user confusion, please do not use the Healthchecks.io logo as your bot's user picture, use your own logo.
After creating the bot you will have the bot's name and token. Put them
TELEGRAM_TOKEN environment variables.
settelegramwebhook management command. This command tells Telegram
where to forward channel messages by invoking Telegram's
setWebhook API call:
./manage.py settelegramwebhook Done, Telegram's webhook set to: https://my-monitoring-project.com/integrations/telegram/bot/
For this to work, your
SITE_ROOT must be correct and must use the "https://"
To enable Apprise integration, you will need to:
ensure you have apprise installed in your local environment:
pip install apprise
enable the apprise functionality by setting the
APPRISE_ENABLED environment variable.
The "Shell Commands" integration runs user-defined local shell commands when checks
go up or down. This integration is disabled by default, and can be enabled by setting
SHELL_ENABLED environment variable to
Note: be careful when using "Shell Commands" integration, and only enable it when
you fully trust the users of your Healthchecks instance. The commands will be executed
manage.py sendalerts process, and will run with the same system permissions as
To enable the Matrix integration you will need to:
MATRIX_environment variables. Example:
MATRIX_HOMESERVER=https://matrix.org MATRIX_USER_ID=@mychecks:matrix.org MATRIX_ACCESS_TOKEN=[a long string of characters returned by the login call]
To enable PagerDuty Simple Install Flow,
Here is a non-exhaustive list of pointers and things to check before launching a Healthchecks instance in production.
manage.py compress– creates combined JS and CSS bundles and places them in the
manage.py collectstatic– collects static files in the
manage.py migrate– applies any pending database schema changes and data migrations.
manage.py runserveris intended for development only. Do not use it in production, instead consider using uWSGI or gunicorn.
manage.py sendalertsis the process that monitors checks and sends out monitoring alerts. It must be always running, it must be started on reboot, and it must be restarted if it itself crashes. On modern linux systems, a good option is to define a systemd service for it.
Healthchecks provides a reference Dockerfile and prebuilt Docker images for every release. The Dockerfile lives in the /docker/ directory, and Docker images for amd64, arm/v7 and arm64 architectures are available on Docker Hub.
The Docker images:
smtpdin the background. You do not need to run them separately.