Install Healthchecks.io on VPS:

What We Are Setting Up and Why

In the modern world, where automation and background processes play a key role in the operation of web applications, databases, and infrastructure, it is critically important to have a reliable way to ensure that all these tasks are executed on time and without errors. This is precisely what Healthchecks.io is designed for.

Healthchecks.io is a powerful tool for monitoring periodic tasks. It operates on the principle of "reverse monitoring": instead of checking if a service is running, Healthchecks.io expects "pings" (HTTP requests) from your tasks at specified intervals. If a task does not send a ping within the expected window, Healthchecks.io immediately sends a failure notification.

It is an ideal solution for:

• Cron Jobs: Ensure that your daily backups, data processing, or report distribution run precisely on schedule.
• Background Processes: Monitoring daemons, queue workers, or other long-running processes that should regularly report their health.
• IoT Devices: Checking the activity of remote devices that should regularly send data.
• Automation Scripts: Confirming the successful completion of automated deployments or synchronizations.

Ultimately, the reader will get a fully functional, self-sufficient monitoring system deployed on their own server. This will provide complete control over data, configuration, and security, and also help avoid costs associated with third-party cloud monitoring services.

Alternatives: Cloud-managed vs Self-hosted

There are many alternatives to Healthchecks.io on the market, both cloud-managed and self-hosted.

• Cloud-managed services: These include solutions such as UptimeRobot, Better Uptime, Cronitor, Pingdom, and Healthchecks.io itself offers a SaaS version.
  • Pros: Easy setup, no server management required, scalability, often rich functionality.
  • Cons: Monthly fees (which can increase with the number of checks), reliance on a third-party provider, potential data privacy concerns.
• Self-hosted solutions: Besides Healthchecks.io, you can consider tools like Prometheus/Grafana (though they are more for metrics than pings), Netdata (for system resource monitoring), or even custom scripts.
  • Pros of self-hosted on a VPS: Full control over data and infrastructure, no monthly payments (other than VPS cost), deep customization possibilities, enhanced privacy.
  • Cons: Requires certain technical knowledge for installation and maintenance, responsibility for security and backups lies with you.

Choosing self-hosted Healthchecks.io on a VPS is justified if you value control, privacy, and want to avoid recurring costs, while possessing sufficient skills to manage your own server. It is a cost-effective and flexible solution for monitoring your critically important tasks.

What VPS Configuration is Needed for This Task

Healthchecks.io is a relatively lightweight application, especially if you use Docker Compose, which optimizes resource consumption. However, for stable operation, particularly considering the PostgreSQL database and web server, certain minimum specifications are required.

Minimum Requirements

• CPU: 1 core. Modern processors are powerful enough to handle tens of thousands of checks.
• RAM: 1-2 GB. This will be sufficient for the operating system, Healthchecks.io Docker containers, and PostgreSQL. If a very large number of checks (hundreds of thousands) is planned, consider 4 GB.
• Disk: 20-40 GB SSD. Healthchecks.io does not store much data by default, but PostgreSQL will grow over time. SSD is critically important for database performance.
• Network: 100 Mbps or 1 Gbps. Basic bandwidth is sufficient for incoming pings and outgoing notifications.

Specific VPS Plan for the Task

For most monitoring scenarios up to several thousand checks, a VPS with the following characteristics will be suitable:

• 2 x vCPU
• 4 GB RAM
• 60-80 GB SSD
• 1 Gbps network interface

Such a configuration will be more than sufficient for stable operation of Healthchecks.io, processing notifications, and storing check history for a long time. You can consider a VPS with the specified characteristics to host your Healthchecks.io instance.

When a Dedicated Server is Needed, Not a VPS

In most cases, a VPS will be sufficient for Healthchecks.io. However, a dedicated server may be justified in the following situations:

• Very large number of checks: If you plan to monitor hundreds of thousands or millions of tasks with very short intervals, which creates a high load on the database and web server.
• Performance requirements: If every millisecond of delay in processing pings or sending notifications is critical, and you want to completely eliminate "noisy neighbor" issues in a virtualized environment.
• Strict security/compliance requirements: Some regulatory requirements may mandate the use of physically isolated hardware.
• Integration with other services: If other critically important services requiring significant resources are planned to be hosted on the same server.

For most users, even with several thousand checks, a well-configured VPS will be the optimal and more economical choice.

Location: What It Affects

Choosing the geographical location of your VPS has several important aspects:

• Latency: The closer the server is to the sources of your pings (your other servers, applications), the lower the latency will be. For Healthchecks.io, this is not critical, as pings are small HTTP requests, but for the overall responsiveness of the system, it can be important.
• Notification availability: If your notifications (e.g., via email) need to reach you quickly, a server location closer to your primary work location might be preferable.
• Legislation and compliance: Depending on what data you plan to monitor and who the user of Healthchecks.io is, the server's location may affect applicable data protection legislation (e.g., GDPR in Europe).
• Price: VPS prices can vary depending on the region.

It is generally recommended to choose a location that is geographically closer to your main services that will send pings, or to your team that will receive notifications.

Server Preparation

Before proceeding with the installation of Healthchecks.io, you need to perform basic setup of your fresh VPS to ensure security and prepare the environment for further deployment. We will use Ubuntu 24.04 LTS (Noble Numbat) as the basis for our tutorial, as it is a current and supported operating system for 2026.

1. Connecting to the Server via SSH

Use an SSH client to connect to your VPS. Replace your_username and your_vps_ip with your actual data.

ssh your_username@your_vps_ip

If you are using the root user, it is recommended to immediately create a new user with limited privileges.

2. Creating a New User and Configuring Sudo

Operating as the root user is insecure. Create a new user and grant them sudo privileges.

# Add a new user
sudo adduser newuser

# Add user to sudo group
sudo usermod -aG sudo newuser

# Switch to the new user
su - newuser

Henceforth, all commands will be executed as newuser using sudo.

3. Configuring SSH Keys (Recommended)

To enhance security, it is recommended to use SSH keys instead of passwords. If you haven't set them up yet, copy your public key to the server.

# On your local machine
ssh-copy-id newuser@your_vps_ip

# On the server, after ensuring key-based login works, disable password login for root
# Edit the /etc/ssh/sshd_config file
sudo nano /etc/ssh/sshd_config

Find and change the following lines:

PermitRootLogin no
PasswordAuthentication no

Save the file (Ctrl+O, Enter) and exit (Ctrl+X). Then restart the SSH service:

sudo systemctl restart sshd

4. System Update

Always start by updating the package list and installing the latest versions of already installed software.

# Update package list
sudo apt update

# Upgrade installed packages to the latest versions
sudo apt upgrade -y

# Remove unnecessary packages and clear cache
sudo apt autoremove -y && sudo apt clean

5. Configuring the Firewall (UFW)

UFW (Uncomplicated Firewall) is an easy-to-use interface for iptables. We will configure it to allow SSH and future Healthchecks.io ports (HTTP/HTTPS).

# Allow SSH (port 22)
sudo ufw allow OpenSSH

# Allow HTTP (port 80) - for Caddy and Let's Encrypt
sudo ufw allow http

# Allow HTTPS (port 443) - for Caddy and Let's Encrypt
sudo ufw allow https

# Enable firewall
sudo ufw enable

Confirm enablement by typing y. Check the firewall status:

sudo ufw status verbose

6. Installing Fail2ban

Fail2ban helps protect your server from brute-force attacks by blocking IP addresses that have too many failed login attempts.

# Install Fail2ban
sudo apt install fail2ban -y

# Enable and start the service
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# Check status (optional)
sudo systemctl status fail2ban

Fail2ban is already configured by default to protect SSH. For more fine-grained configuration, you can copy and edit the /etc/fail2ban/jail.conf file to /etc/fail2ban/jail.local.

7. Installing Basic Utilities

Let's install a few useful utilities that might come in handy later.

# Install curl, wget, git, htop
sudo apt install curl wget git htop -y

Your server is now ready for the installation of Healthchecks.io and its dependencies.

Software Installation — Step-by-Step

To install Healthchecks.io, we will use Docker Compose. This is the most recommended deployment method, as it simplifies dependency management (PostgreSQL, Redis) and updates. We will use the latest versions of Docker and Healthchecks.io available in 2026.

1. Installing Docker and Docker Compose

First, let's install Docker Engine and Docker Compose. We will use the official Docker repositories to get the latest versions.

# Remove old Docker versions (if any)
sudo apt remove docker docker-engine docker.io containerd runc

# Install dependencies to add the Docker repository
sudo apt install apt-transport-https ca-certificates curl software-properties-common -y

# Add Docker's GPG key
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# Add Docker repository
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Update package list after adding the repository
sudo apt update

# Install Docker Engine, Docker CLI, and containerd (latest versions for 2026)
sudo apt install docker-ce docker-ce-cli containerd.io -y

# Add the current user to the docker group to run commands without sudo
sudo usermod -aG docker ${USER}

# Apply group changes (requires re-connecting to SSH or rebooting)
# newgrp docker
# Execute exit and reconnect to the server via SSH for the changes to take effect.

After reconnecting to SSH, verify the Docker installation:

# Check Docker version
docker --version

# Check Docker Compose version (will be installed as a plugin)
docker compose version

Expected versions: Docker Engine 25.x.x+, Docker Compose v2.x.x+.

2. Downloading Healthchecks.io Configuration

We will use the official Healthchecks.io repository to obtain the docker-compose.yml file and related files.

# Create directory for Healthchecks.io
mkdir ~/healthchecks
cd ~/healthchecks

# Download docker-compose.yml and .env.example files
# Use wget to download directly from GitHub for stability
wget https://raw.githubusercontent.com/healthchecks/healthchecks/master/docker-compose.yml
wget https://raw.githubusercontent.com/healthchecks/healthchecks/master/.env.example

# Rename example environment variables file
mv .env.example .env

3. Configuring the .env file

The .env file contains critically important environment variables for Healthchecks.io, including the secret key, database connection details, and email settings. Open it for editing:

# Open .env file for editing
nano .env

Be sure to change the following parameters:

• SECRET_KEY: Generate a very long random string (e.g., 50+ characters) using a password generator or the command openssl rand -hex 32. This key is used for cryptographic operations.
• SITE_ROOT: Specify the full URL of your Healthchecks.io instance, for example, https://monitor.yourdomain.com. This is important for the correct functioning of links in notifications and the web interface.
• DB_HOST, DB_NAME, DB_USER, DB_PASS: Use the default values from docker-compose.yml (usually db, hc, hc, hc), but MANDATORY to change DB_PASS to a strong random password.
• EMAIL_HOST, EMAIL_PORT, EMAIL_HOST_USER, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, DEFAULT_FROM_EMAIL: Configure these parameters for sending email notifications. Use your SMTP provider's details. If you do not configure this, Healthchecks.io will not be able to send notifications.
• PING_KEY: Generate a unique key (e.g., UUID) that will be used for authorization when sending pings, if you want to enhance security. If not specified, an internal mechanism is used.

Example of edited lines in .env:

SECRET_KEY='your_very_long_and_random_secret_key_here_e.g._openssl_rand_hex_32_output'
SITE_ROOT='https://monitor.yourdomain.com'

DB_HOST=db
DB_NAME=hc
DB_USER=hc
DB_PASSWORD='your_strong_db_password_here'

EMAIL_HOST=smtp.mailtrap.io
EMAIL_PORT=2525
EMAIL_HOST_USER=your_smtp_username
EMAIL_HOST_PASSWORD=your_smtp_password
EMAIL_USE_TLS=True
[email protected]

PING_KEY='your_optional_ping_key_uuid'

Save changes (Ctrl+O, Enter) and exit (Ctrl+X).

4. Database Initialization

Before the first launch of Healthchecks.io, it is necessary to initialize the database and apply migrations.

# Start database container and run migrations
docker compose run --rm web python manage.py migrate

This command starts the web container, executes the python manage.py migrate command to create the necessary tables in the database, and then removes the container (--rm).

5. Creating a Superuser

To access the Healthchecks.io administrative panel, you need to create a superuser account.

# Start web container and create superuser
docker compose run --rm web python manage.py createsuperuser

You will be prompted to enter a username, email address, and password. Use a strong password.

6. Starting Healthchecks.io

Now you can start all Healthchecks.io services in the background.

# Start all services in the background
docker compose up -d

Verify that the containers are running:

# Check the status of running containers
docker compose ps

You should see Up statuses for the db, redis, and web containers.

At this point, Healthchecks.io is running and accessible on port 8000 within the Docker network. The next step is to configure the Caddy web server for external access and HTTPS.

Configuration

After installing the basic components of Healthchecks.io, it is necessary to configure external access to the application via a domain name and ensure connection security using HTTPS. We will use Caddy — a modern web server that automatically manages Let's Encrypt certificates.

Important note: Before proceeding, ensure that your domain (e.g., monitor.yourdomain.com) points to the IP address of your VPS. Add the corresponding A-record in your domain registrar's DNS settings.

1. Installing Caddy

Caddy can be installed from the official repository. This will ensure up-to-date versions and ease of updates.

# Install dependencies to add the Caddy repository
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https

# Add Caddy's GPG key
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg

# Add Caddy repository
echo "deb [signed-by=/usr/share/keyrings/caddy-stable-archive-keyring.gpg] https://dl.cloudsmith.io/public/caddy/stable/deb/debian $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/caddy-stable.list

# Update package list
sudo apt update

# Install Caddy (latest version for 2026)
sudo apt install caddy -y

# Check Caddy version
caddy version

Expected version: Caddy 2.x.x+.

2. Configuring the Caddyfile

The Caddyfile is Caddy's main configuration file. We will create it to proxy requests to our Healthchecks.io container.

# Open Caddyfile for editing
sudo nano /etc/caddy/Caddyfile

Remove all existing content and add the following configuration, replacing monitor.yourdomain.com with your actual domain:

monitor.yourdomain.com {
    # Proxy all requests to the Healthchecks.io container
    reverse_proxy 127.0.0.1:8000 {
        # Headers for correct proxying operation
        header_up Host {host}
        header_up X-Real-IP {remote_ip}
        header_up X-Forwarded-For {remote_ip}
        header_up X-Forwarded-Proto {scheme}
    }

    # Enable compression (optional, but recommended)
    encode gzip zstd

    # Access logging (optional)
    log {
        output file /var/log/caddy/access.log
        format json
    }

    # Error handling (optional)
    handle_errors {
        respond "{err.status_code} {err.status_text}" {err.status_code}
    }
}

Explanation:

• monitor.yourdomain.com: Specifies the domain to which this configuration applies. Caddy will automatically obtain an HTTPS certificate for it.
• reverse_proxy 127.0.0.1:8000: Redirects all incoming requests to local port 8000, where Healthchecks.io is running (within the Docker network, it is accessible via 127.0.0.1 if ports: - "127.0.0.1:8000:8000" is specified in docker-compose.yml).
• header_up ...: Passes the original host headers, IP address, and protocol scheme to Healthchecks.io, which is important for the correct functioning of the application, especially when generating links.

Save the file (Ctrl+O, Enter) and exit (Ctrl+X).

3. Creating a Directory for Caddy Logs

If you enabled logging in the Caddyfile, ensure that the log directory exists and Caddy has access to it.

# Create directory for Caddy logs
sudo mkdir -p /var/log/caddy

# Set correct permissions
sudo chown caddy:caddy /var/log/caddy

4. Restarting Caddy

Apply the new configuration by restarting the Caddy service.

# Check Caddyfile configuration for errors
sudo caddy validate --config /etc/caddy/Caddyfile

# Restart Caddy service
sudo systemctl restart caddy

# Ensure Caddy is running and active
sudo systemctl status caddy

In the systemctl status caddy output, you should see active (running).

5. Configuring the Firewall for Caddy

We already opened ports 80 and 443 during the server preparation phase, but if you haven't, make sure they are open.

# Allow HTTP (port 80)
sudo ufw allow 80/tcp

# Allow HTTPS (port 443)
sudo ufw allow 443/tcp

# Reload UFW if changes were made
sudo ufw reload

6. Verifying Functionality

Now you can check the availability of Healthchecks.io via your domain.

• Via browser: Open https://monitor.yourdomain.com in your web browser. You should see the Healthchecks.io login page.
• Via curl on the server:

# Check availability via HTTPS
curl -I https://monitor.yourdomain.com

You should see HTTP response headers, including HTTP/2 200 and headers indicating Healthchecks.io.

• Checking Caddy logs:

# View Caddy logs
sudo journalctl -u caddy -f
# Or if configured to a file:
sudo tail -f /var/log/caddy/access.log

You should see entries for incoming requests and successful responses.

If everything is configured correctly, Healthchecks.io should be fully accessible via your domain with a secure HTTPS connection. You can now log in using the superuser created earlier and start adding your first checks.

Configuration

Backups and Maintenance

Regular backups and timely maintenance are key to the reliability of any system. Healthchecks.io is no exception. In this section, we will look at what exactly needs to be backed up, how to automate the process, and how to keep the system up to date.

1. What to Back Up

For a full recovery of Healthchecks.io, you will need to save three main types of data:

• PostgreSQL Database: Contains all your checks, pings, user settings, event history, and notifications. This is the most critical component.
• .env Configuration File: Contains the secret key, SMTP settings, API keys, and other important parameters.
• Caddyfile Configuration: Although it's easy to recreate, saving the current version can save time during recovery.

2. Simple Auto-Backup Script

Let's create a simple script that will dump the database and copy configuration files.

# Создание директории для скриптов бэкапа
mkdir -p ~/backups
nano ~/backups/backup_healthchecks.sh

Add the following content to the backup_healthchecks.sh file. Replace /path/to/healthchecks with the actual path to your Healthchecks.io directory (e.g., /home/newuser/healthchecks).

#!/bin/bash

# Каталог, где находятся файлы Healthchecks.io
HEALTHCHECKS_DIR="/home/newuser/healthchecks"
# Каталог для хранения бэкапов
BACKUP_DIR="/home/newuser/backups/healthchecks_data"
# Имя файла дампа базы данных
DB_DUMP_FILE="healthchecks_db_$(date +%Y%m%d_%H%M%S).sql.gz"
# Количество дней для хранения локальных бэкапов
RETENTION_DAYS=7

# Создание директории для бэкапов, если ее нет
mkdir -p "${BACKUP_DIR}"

echo "--- Начинаем процесс резервного копирования Healthchecks.io ---"

# 1. Бэкап базы данных PostgreSQL
echo "Дампинг базы данных PostgreSQL..."
docker compose -f "${HEALTHCHECKS_DIR}/docker-compose.yml" exec -T db pg_dumpall -U hc | gzip > "${BACKUP_DIR}/${DB_DUMP_FILE}"

if [ $? -eq 0 ]; then
    echo "База данных успешно сохранена в ${BACKUP_DIR}/${DB_DUMP_FILE}"
else
    echo "ОШИБКА: Не удалось сохранить базу данных."
    exit 1
fi

# 2. Копирование файла .env
echo "Копирование файла .env..."
cp "${HEALTHCHECKS_DIR}/.env" "${BACKUP_DIR}/.env_$(date +%Y%m%d_%H%M%S)"

if [ $? -eq 0 ]; then
    echo "Файл .env успешно скопирован."
else
    echo "ОШИБКА: Не удалось скопировать файл .env."
fi

# 3. Копирование Caddyfile
echo "Копирование Caddyfile..."
sudo cp /etc/caddy/Caddyfile "${BACKUP_DIR}/Caddyfile_$(date +%Y%m%d_%H%M%S)"

if [ $? -eq 0 ]; then
    echo "Caddyfile успешно скопирован."
else
    echo "ОШИБКА: Не удалось скопировать Caddyfile."
fi

# 4. Удаление старых бэкапов (старше RETENTION_DAYS)
echo "Удаление старых бэкапов (старше ${RETENTION_DAYS} дней)..."
find "${BACKUP_DIR}" -type f -name "healthchecks_db_*.sql.gz" -mtime +"${RETENTION_DAYS}" -delete
find "${BACKUP_DIR}" -type f -name ".env_*" -mtime +"${RETENTION_DAYS}" -delete
find "${BACKUP_DIR}" -type f -name "Caddyfile_*" -mtime +"${RETENTION_DAYS}" -delete
echo "Старые бэкапы удалены."

echo "--- Процесс резервного копирования завершен ---"

Make the script executable:

chmod +x ~/backups/backup_healthchecks.sh

3. Where to Store Backups (External Storage)

Storing backups on the same server as the original data is extremely risky. In case of server failure or data loss, you will lose your backups as well. Be sure to configure copying backups to external, geographically remote storage:

• S3-compatible storage (AWS S3, DigitalOcean Spaces, Backblaze B2): The most reliable and scalable option. Use awscli or rclone for automatic synchronization.
• Separate VPS: You can set up a second, cheaper VPS and use rsync or scp to copy backups over SSH.
• NFS/SMB Share: If you have network storage, you can mount it and copy files there.

Example of adding S3 synchronization using awscli (assuming awscli is installed and configured):

# Добавьте в ваш скрипт backup_healthchecks.sh после секции "Удаление старых бэкапов":
echo "Синхронизация бэкапов с S3..."
/usr/local/bin/aws s3 sync "${BACKUP_DIR}" s3://your-s3-bucket-name/healthchecks/
if [ $? -eq 0 ]; then
    echo "Бэкапы успешно синхронизированы с S3."
else
    echo "ОШИБКА: Не удалось синхронизировать бэкапы с S3."
fi

Don't forget to configure awscli on the server with appropriate credentials and access rights to your S3 bucket.

4. Automation with Cron

Add the backup script to Cron for automatic execution. For example, for a daily backup at 03:00 AM:

# Открытие crontab для текущего пользователя
crontab -e

Add the following line to the end of the file:

0 3 * * * /home/newuser/backups/backup_healthchecks.sh >> /home/newuser/backups/backup.log 2>&1

This line runs the script every day at 03:00 and redirects all output (including errors) to the backup.log file for later review.

5. Updates: Rolling vs Maintenance Window

Regular updates are critically important for security and new features.

• OS Update: Recommended to perform monthly.

  
  sudo apt update && sudo apt upgrade -y
  sudo apt autoremove -y && sudo apt clean
  

• Docker Container Update (Healthchecks.io, PostgreSQL, Redis):

  Healthchecks.io is updated by pulling new Docker images. This can be done without significant downtime (rolling update) if you are using multiple instances, but for a single VPS, a short maintenance window will be required.

  
  cd ~/healthchecks
  # Остановка сервисов
  docker compose down
  
  # Получение последних образов
  docker compose pull
  
  # Запуск сервисов с новыми образами
  docker compose up -d
  
  # Удаление старых, неиспользуемых образов и томов
  docker system prune -f
  docker volume prune -f
  

  It is recommended to perform these steps during a pre-defined maintenance window to minimize impact on users. Before updating, always check the official Healthchecks.io documentation for configuration changes or database migrations that may require additional steps.

Remember that regularly testing the backup recovery process is as important as creating the backups themselves. This ensures that in the event of a failure, you can quickly restore your system.

Troubleshooting + FAQ

Even with the most careful setup, problems can arise. This section will help you diagnose and resolve the most common issues, as well as answer frequently asked questions.

Cannot access Healthchecks.io via browser. What to check?

If you cannot open the Healthchecks.io web interface using your domain name (e.g., https://monitor.yourdomain.com), check the following:

1. DNS Record: Ensure that your domain's A-record correctly points to your VPS's IP address. Use dig monitor.yourdomain.com or online tools.
2. Firewall (UFW): Check if ports 80 (HTTP) and 443 (HTTPS) are open on your VPS. Use sudo ufw status verbose.
3. Caddy: Ensure that the Caddy service is running (sudo systemctl status caddy) and that its configuration file (/etc/caddy/Caddyfile) is correctly configured and points to the correct port (127.0.0.1:8000). Check Caddy logs: sudo journalctl -u caddy -f.
4. Docker Containers: Ensure that all Healthchecks.io containers are running: cd ~/healthchecks && docker compose ps. All containers (db, redis, web) should be in Up status.
5. SITE_ROOT in .env: Ensure that the SITE_ROOT variable in the .env file is set to the full HTTPS URL of your domain (e.g., https://monitor.yourdomain.com).

Healthchecks.io (web) container does not start or constantly restarts.

This usually indicates a configuration or dependency issue. Check the container logs:

cd ~/healthchecks
docker compose logs web

Look for error messages in the output. Typical causes:

• Database Issues: Incorrect credentials in .env (DB_USER, DB_PASSWORD), or the db container is not running.
• Incorrect SECRET_KEY: SECRET_KEY must be a long, random string.
• Migration Issues: Ensure that python manage.py migrate was executed successfully.
• Redis Issues: The redis container is not running or is inaccessible.

Email notifications are not being received.

Check the following points:

1. SMTP Settings in .env: Ensure that all variables EMAIL_HOST, EMAIL_PORT, EMAIL_HOST_USER, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, and DEFAULT_FROM_EMAIL in the .env file are correctly configured for your SMTP provider.
2. Test Email: Try sending a test email from the Healthchecks.io console:

   
   cd ~/healthchecks
   docker compose run --rm web python manage.py sendtestemail [email protected]
               

   This should show sending errors, if any.

3. VPS Firewall: Ensure that your VPS can establish outgoing connections to your provider's SMTP port (usually 587 or 465).
4. Spam Filters: Check your "Spam" folder in your mailbox.

Pings are not being registered in Healthchecks.io.

If your tasks are sending pings, but Healthchecks.io is not seeing them:

1. Ping URL: Ensure that the URL your task uses to send the ping is absolutely accurate (including the check's UUID). It should be in the format https://monitor.yourdomain.com/ping/YOUR_CHECK_UUID/.
2. Network Accessibility: Ensure that the server sending the ping can reach your Healthchecks.io instance. Check using curl -I https://monitor.yourdomain.com from the server sending the ping.
3. PING_KEY: If you have set the PING_KEY variable in .env, ensure that your tasks are sending this key in the X-Ping-Key header.
4. Time Zone: Ensure that the time zones on your VPS and in Healthchecks.io are configured correctly to avoid scheduling issues.

What is the minimum suitable VPS configuration?

For basic use of Healthchecks.io, monitoring dozens or even a couple of hundred tasks, a VPS with 1 vCPU, 1-2 GB RAM, and 20-40 GB SSD will be minimally suitable. This will be sufficient for the operating system, Docker, Healthchecks.io, and its database. However, for greater stability and growth potential, 2 vCPU, 4 GB RAM, and 60-80 GB SSD are recommended.

What to choose — VPS or dedicated for this task?

For most users and monitoring scenarios, Healthchecks.io on a VPS is the optimal solution. It is cost-effective, sufficiently performant, and provides the necessary level of isolation. Dedicated servers are justified only in very specific cases: when monitoring hundreds of thousands or millions of tasks, when maximum performance and complete absence of "noisy neighbor" issues are required, or when there are strict requirements for physical isolation of equipment.

Conclusions and Next Steps

Congratulations! You have successfully installed and configured Healthchecks.io on your VPS, providing reliable monitoring for your Cron jobs and background processes. You now have full control over your monitoring system, ensuring timely notifications of any failures or delays in your critical tasks. This will significantly increase the reliability of your infrastructure and allow you to respond quickly to issues.

Next Steps

1. Notification Integration: Configure additional Healthchecks.io notification channels, such as Slack, Telegram, PagerDuty, or custom webhooks, to receive alerts in the most convenient way for you.
2. Additional Checks: Start adding all your periodic tasks to Healthchecks.io. Consider monitoring not only scripts but also regular operations such as cache updates, disk space checks, or log cleanup.
3. Server Resource Monitoring: For a complete overview of your system's health, consider installing an additional server resource monitoring tool, such as Netdata or Prometheus/Grafana, to track your VPS's CPU, RAM, disk, and network.