What Is Heartbeat Monitoring and How Does It Differ from Uptime Monitoring?
Conventional uptime monitoring works on the pull principle: a monitoring server regularly queries your website and checks for a response. This works for web servers, APIs, and publicly accessible services. But cron jobs, background processes, and internal tasks are not reachable from outside. They have no URL to query.
Heartbeat monitoring reverses the principle: it works on the push principle. At the end of a cron job, the process sends an HTTP request (ping) to a predefined URL at the monitoring service. The monitoring service expects this ping at a defined interval. If the ping is missed, an alert is triggered. Instead of checking reachability, it checks execution.
Pull (Uptime monitoring): Monitoring queries the service. Suitable for websites, APIs, public endpoints. Push (Heartbeat monitoring): The process reports to monitoring. Suitable for cron jobs, backups, batch processing, internal processes.
Why Cron Jobs Are Particularly Prone to Unnoticed Failures
Cron jobs have several characteristics that make them particularly susceptible to unnoticed failures. They run automatically at defined times, often at night or on weekends when nobody is watching. When a cron job fails, it writes an error to the log at best, which nobody reads. The output goes to a local mailbox that is not configured.
Typical Failure Causes
- Disk full: A backup script fails because no storage space is available. The backup is missing, but nobody notices until a restore is needed
- Dependency unavailable: A data import job cannot reach the source database because credentials have changed or the server was restarted
- Timeout: A report generator job runs longer than expected and is killed by the cron daemon before it can save the result
- Permission error: After a server update, file permissions have changed. The script can no longer access the required directories
- Crontab deleted: During a server update or migration, the crontab is accidentally deleted. The jobs simply stop running without an error message
- Environment variables missing: Cron runs jobs in a minimal shell environment. Environment variables available in the normal shell are missing in the cron context
Heartbeat Monitoring in Practice: Step by Step
Step 1: Create Heartbeat Endpoint
In XICTRAQ, you create a heartbeat monitor with a unique name (e.g., DB-Backup-Nightly) and define the expected interval. XICTRAQ generates a unique URL to which your cron job sends the ping. Optionally, you can set a grace period: a tolerance time before a missed ping is counted as a failure.
Step 2: Adapt Your Cron Job
At the end of your cron job script, you add an HTTP request that reports successful completion. The simplest method is a curl command: curl -fsS --retry 3 https://api.xictraq.com/api/heartbeat/abc123/ping. The -f flag ensures curl returns a non-zero exit code on HTTP errors. --retry 3 retries the ping up to three times on network problems.
Step 3: Distinguish Success from Failure
Advanced heartbeat monitoring distinguishes between success, failure, and timeout. Instead of only sending a ping on success, you can include the script's exit code. XICTRAQ evaluates this and can differentiate between a failed job (non-zero exit code) and a missed job (no ping received).
An example: your backup script runs but the backup fails. Without exit code transmission, the ping still reports success. With the exit code, XICTRAQ recognizes that the job ran but failed and sends an appropriate alert.
Which Processes Should Be Monitored via Heartbeat?
As a rule, every automated process whose failure is not immediately visible should be monitored. The following categories are particularly critical.
| Process | Typical Interval | Consequence of Failure | Priority |
|---|---|---|---|
| Database backups | Daily / hourly | Data loss on crash | Critical |
| Email queue processing | Every 5-15 minutes | Emails not sent | Critical |
| SSL certificate renewal | Weekly / daily | Expired certificate, website outage | Critical |
| Data imports / sync | Hourly / daily | Stale data, inconsistencies | High |
| Log rotation | Daily | Disk fills up | High |
| Report generation | Daily / weekly | Missing reports, delayed decisions | Medium |
| Cache cleanup | Hourly / daily | Stale content, memory issues | Medium |
| Sitemap generation | Daily | Outdated sitemap, SEO issues | Medium |
Grace Periods and Alert Configuration
Not every delayed ping is a problem. Cron jobs can take longer than usual for various reasons: larger data volumes, slower database queries, or brief network issues. The grace period defines how long to wait after the expected ping time before triggering an alert.
The right grace period depends on the process. A backup job that normally takes 10 minutes may need 30 minutes with large data volumes. A grace period of 20 minutes beyond the normal interval prevents false alarms while still detecting real failures in time. XICTRAQ allows individual grace period configuration per heartbeat monitor.
Multi-Level Alerts
- Warning (grace period exceeded): The ping is late but still within an extended tolerance. Email to the team
- Critical (ping missed): No ping within the interval plus grace period. Email + webhook + optional SMS
- Recovery: When the next ping arrives, an all-clear is automatically sent
- Repeated failure: Multiple consecutive misses escalate the alert to additional recipients
Integration into Existing Workflows
Shell Scripts
For shell-based cron jobs, integration is simplest. A curl or wget command at the end of the script suffices. Important: place the ping after the success logic, not unconditionally at the end. If the script fails, no success ping should be sent.
Python, Node.js, and Other Languages
In application code, use the respective language's HTTP library. In Python: requests.get('https://api.xictraq.com/api/heartbeat/abc123/ping'). In Node.js: fetch('https://api.xictraq.com/api/heartbeat/abc123/ping'). Wrap the ping in a try-catch block so a network error on the ping doesn't crash the entire job.
Kubernetes CronJobs
In Kubernetes environments, cron jobs are defined as CronJob resources. The heartbeat ping is configured as the last step in the container entrypoint or as a sidecar container. While Kubernetes offers its own job monitoring mechanisms, heartbeat monitoring adds an external perspective that also detects Kubernetes-specific issues (scheduler failure, node draining).
Heartbeat Monitoring for Backups: The Most Important Use Case
Backups are the most important use case for heartbeat monitoring. A backup that was not created is worthless, and you only find out when you need it. That is the worst possible time. According to a Veeam study, 58 percent of companies have experienced a situation where a needed backup was missing or incomplete (Veeam Data Protection Trends Report).
Heartbeat monitoring for backups should check not just execution but also success. Send the backup size and duration as parameters alongside the ping. XICTRAQ can then also detect anomalous backups: a backup that is suddenly only 10% of the usual size indicates a problem, even if the job itself completed successfully.
Detecting Silent Failures: Real Scenarios
The Let's Encrypt renewal job has been failing for two weeks because the DNS configuration changed. Without heartbeat monitoring, this is only noticed when the certificate expires and the website becomes unreachable.
The backup server's disk is full. The backup script fails every night, but nobody reads the cron log. Only when data is lost is the missing backup noticed.
The process that handles the email queue has crashed. Customer notifications, order confirmations, and password resets are not sent. Support requests pile up.
A nightly import job fails due to changed API credentials. Product data in the shop is outdated, but the website shows no error message.
Combining Heartbeat and Uptime Monitoring
Heartbeat monitoring does not replace uptime monitoring but complements it. Uptime monitoring checks the reachability of your website and API endpoints. Heartbeat monitoring checks the execution of internal processes. Together, they provide a complete picture of system health.
XICTRAQ integrates both monitoring types in a single dashboard. You see at a glance: Is the website reachable? Are all cron jobs running? Are security headers correct? Is the SSL certificate valid? Are there DNS anomalies? Is GDPR compliance maintained?
Best Practices for Heartbeat Monitoring
- Give every critical job its own heartbeat: Don't combine multiple jobs into one ping. If one of three jobs fails, you won't know which one
- Only ping on success: The heartbeat ping should only be sent after successful execution, not unconditionally at the script's end
- Include exit codes: Transmit the exit code or a status field so monitoring can distinguish between success and failure
- Configure grace periods individually: A 5-minute job needs a different grace period than a 2-hour import
- Handle network errors on ping: A failed ping request should not mark the entire job as failed. Use retry logic
- Define alerting chains: Who is notified first on a cron job failure? Who escalates after 30 minutes without response?
XICTRAQ: Heartbeat Monitoring as Part of the Complete Solution
Heartbeat monitoring in XICTRAQ is seamlessly integrated into the existing monitoring infrastructure. Cron job failures appear in the same dashboard as website outages, performance issues, and security findings.
- Unified dashboard: Uptime monitoring, heartbeat monitoring, and security scans at a glance
- Flexible intervals: From every minute to weekly, with individual grace period per monitor
- Multiple notification channels: Email, webhook, Slack integration individually configurable for each heartbeat monitor
- Historical data: Complete ping history with timestamp, duration, and status for error analysis and trend evaluation
- Reporting: Heartbeat status included in regular monitoring reports
Start now with a free demo and see how XICTRAQ monitors your cron jobs. Or register directly to reliably detect silent failures before they cause damage.
What is the difference between heartbeat monitoring and uptime monitoring?
What happens if the heartbeat ping cannot be delivered?
Can I send my cron job's exit code?
How many heartbeat monitors can I set up?
Does heartbeat monitoring work with Docker containers and Kubernetes?
What is a sensible grace period?
This article is based on data from: Data Protection Trends (Veeam).