Setting Up Healthchecks.io for Cron Job and Backup Monitoring
Cron jobs fail silently. A backup stopped running three weeks ago — nobody noticed until a recovery was needed. We solve this for our clients by deploying Healthchecks.io as a dead man's switch layer on top of existing cron infrastructure: instead of checking whether a service is alive, it verifies that each scheduled task reports execution on time. No ping arrives in the expected window — the alert fires immediately, before any data loss accumulates.
The service works in both cloud and self-hosted modes. The cloud version at healthchecks.io requires no infrastructure to start: create a check, append a curl call at the end of your script, configure notification channels. The self-hosted version is fully open source and suits compliance-sensitive or air-gapped environments — same interface, all monitoring data stays on your own servers.
We integrate Healthchecks.io as part of backup infrastructure setup or as a standalone scheduled-job audit. Connecting 5–10 checks takes 2–4 hours. Full coverage of all production cron jobs with proper notification routing and runbook documentation takes one working day. Contact us for an estimate tailored to your environment — we assess the project scope and respond within 24 hours.
How Healthchecks.io Monitors Cron Jobs
Dead Man's Switch Mechanism
Create a check with an expected period (for example, every 24 hours) and a grace period — typically 1 hour — as a buffer. At the end of the cron job add an HTTP request to the check's unique URL. If no request arrives within period + grace, Healthchecks.io fires a notification.
# /etc/cron.d/backup
0 2 * * * root /opt/scripts/backup.sh && curl -fsS --retry 3 https://hc-ping.com/your-uuid-here > /dev/null 2>&1The && operator is critical: curl executes only after backup.sh exits with code 0. A failed script produces no ping, the check misses its window, and the alert fires. This is the correct pattern — never ping unconditionally.
Self-hosted Deployment for Private Infrastructure
Healthchecks.io is open source. For sensitive environments or offline setups, deploy your own instance:
services:
web:
image: healthchecks/healthchecks:latest
environment:
- SECRET_KEY=your-secret-key-here
- ALLOWED_HOSTS=healthchecks.example.com
- [email protected]
- EMAIL_HOST=smtp.example.com
ports:
- "8000:8000"
volumes:
- healthchecks-db:/dataAfter deployment the interface is identical to the cloud version. All ping history, check configurations, and notification settings remain on your infrastructure.
Backup Monitoring with Healthchecks.io
Verifying Integrity, Not Just Execution
A ping at the end of a backup script confirms the script ran to completion — not that the backup file is valid and restorable. Add size validation before pinging to catch corrupted or empty archives:
#!/bin/bash
set -e
BACKUP_FILE="/backups/db_$(date +%Y%m%d).sql.gz"
pg_dump -h localhost -U app mydb | gzip > "$BACKUP_FILE"
MIN_SIZE=10240
ACTUAL_SIZE=$(stat -c%s "$BACKUP_FILE")
if [ "$ACTUAL_SIZE" -lt "$MIN_SIZE" ]; then
echo "Backup too small: $ACTUAL_SIZE bytes" >&2
exit 1
fi
curl -fsS --retry 3 "https://hc-ping.com/${HC_UUID}" > /dev/null
This pattern catches corrupt or suspiciously small backups that would otherwise go unnoticed until actual restore time — when the cost of failure is highest.
What Our Clients Monitor with Healthchecks.io
In our practice, the most common targets for Healthchecks.io integration across client infrastructure are:
- Database backups — pg_dump, mysqldump, Barman and WAL-G tasks
- Data synchronization to object storage — rsync, rclone to S3, GCS, or B2
- Log rotation and archiving — logrotate, custom log shipping scripts
- ETL report generation — nightly data exports and warehouse loads
- SSL certificate renewal — certbot renew, especially for ACME and wildcard setups
- Prometheus Pushgateway metric collection when using a push-based model
For each job we create a named check with a descriptive schedule and connect it to the appropriate channel: production backups and databases go to PagerDuty with escalation; report generation and log rotation go to a team Telegram channel or email.
Notification Integrations
Healthchecks.io supports Slack, PagerDuty, Telegram, email, webhook, and dozens of additional integrations. Configuration happens via the web interface and takes minutes per channel. We recommend tiered alerting: critical jobs with on-call escalation and less critical jobs with asynchronous notifications, so engineers are not woken up for a delayed ETL export.
For production-grade setups we configure notification channels before connecting any checks, test each channel manually, and document the escalation path in a runbook alongside the check's expected behavior.
What Is Included in the Healthchecks.io Setup
- Audit of existing cron jobs, backup scripts, and scheduled tasks.
- Installation and configuration of cloud or self-hosted Healthchecks.io.
- Integration of ping calls into all production cron scripts and backup jobs.
- Backup integrity checks — file size validation, age checks, optional restore verification.
- Notification routing setup across PagerDuty, Telegram, Slack, and email.
- Runbook documentation for each monitored job with expected schedule and recovery steps.
- Post-implementation support and adjustments.
Timeline
| Scope | Duration |
|---|---|
| Cloud Healthchecks.io, 5–10 checks | 2–4 hours |
| Self-hosted deployment and notification setup | 4–8 hours |
| Full cron audit and production coverage | 1 working day |
Our team has 10+ years of DevOps experience and has configured Healthchecks.io for 40+ production environments — from single-server setups to multi-service infrastructure with hundreds of scheduled jobs. Certified engineers, documented runbooks, guaranteed coverage of all critical cron tasks.
Cost is calculated per project based on the number of cron jobs, backup scripts, and notification integrations involved. Contact us to assess the project and get a precise estimate within 24 hours.







