Heartbeat Ping: Application Monitoring Signals

The heartbeat ping is a monitoring mechanism based on a simple but powerful principle: your application regularly sends a signal to a monitoring service to prove it's alive and functioning correctly. The absence of this signal triggers an alert, allowing detection of failures that would otherwise go unnoticed.

Unlike classic HTTP monitoring that tests URL availability from the outside, the heartbeat ping is emitted from inside your application. This "inside-out" approach allows monitoring of processes that don't expose an HTTP interface: crons, queue workers, batch scripts, data synchronizations. If the process doesn't run or crashes before completion, no ping is sent and you're alerted.

This technique is particularly effective for processes that run periodically and whose failure can go unnoticed for days: automatic backups, data imports, report generation, temporary file cleanup. The heartbeat ping ensures you'll be alerted if any of these critical processes stops working.

How Heartbeat Ping Works

The heartbeat ping mechanism relies on four components working together to ensure reliable monitoring of your processes.

• Periodic signal: Your application or script sends a simple HTTP call (GET or POST) to a unique URL provided by MoniTao. This signal can be sent at fixed intervals (every minute for a service) or after each successful execution (for a daily cron).
• Configured expectation: MoniTao knows the expected frequency of your pings. If you configure a daily heartbeat, the system expects a ping every 24 hours. A configurable grace period absorbs normal timing variations.
• Absence detection: If the ping doesn't arrive within the configured delay (interval + grace period), MoniTao changes the job status to "late", then "failed". It's the absence of signal that triggers the alert, not an active error.
• Immediate alert: As soon as the status changes to "failed", you receive a notification via your configured channels: email, SMS, webhook, Slack. The alert indicates the job name, time of last ping, and observed delay.

When to Send the Heartbeat Ping

The placement of the ping in your code is crucial for effective monitoring. Here are different situations and associated best practices.

• Successful execution end: The most common case is sending the ping at the very end of a job or script, only if execution completed successfully. Place the call after all critical operations and after result verification. If an error occurs, the ping isn't sent and you're alerted.
• Service loop: For a long-running service (queue worker, daemon), send a ping at fixed intervals (every 1-5 minutes) in the main loop. This proves the service is alive and processing messages. If the process freezes or dies, pings stop.
• After business validation: For some jobs, technical execution can succeed but business results be incorrect (0 records processed, empty file generated). Add validation before the ping: verify that data was actually processed, that the backup file has a reasonable size.
• Conditional start jobs: Some jobs only execute if a condition is met (data to process, specific time). In this case, ping even when there's nothing to do - this proves the job ran and checked the condition. Otherwise, you can't distinguish "no work" from "job didn't run".

Integration Examples by Language

Here are complete examples of heartbeat ping integration in different languages and contexts. All examples include proper error handling and best practices.

Bash / Shell (Crontab)

#!/bin/bash
# Backup script with heartbeat ping

PING_URL="https://ping.monitao.com/p/YOUR_TOKEN"

# Execute backup
/usr/bin/mysqldump -u root -p'password' mydb > /backup/db.sql
RESULT=$?

# Ping only if backup succeeded
if [ $RESULT -eq 0 ]; then
    # Verify file is not empty
    if [ -s /backup/db.sql ]; then
        curl -fsS --retry 3 --max-time 10 "$PING_URL" > /dev/null
        echo "Backup OK, ping sent"
    else
        echo "Empty backup file, no ping"
        exit 1
    fi
else
    echo "Backup error, no ping"
    exit 1
fi

This script checks not only the mysqldump return code but also that the generated file isn't empty. Curl uses --retry 3 to retry on temporary network issues, and --max-time 10 to avoid blocking indefinitely.

PHP (Laravel / Symfony)

generateReports();

            // Validation: at least some reports generated
            if ($count === 0) {
                $this->warn('No reports generated');
                // Still ping since job did execute
            }

            // Ping with metrics
            Http::timeout(10)->retry(3)->post(
                'https://ping.monitao.com/p/YOUR_TOKEN',
                ['duration' => $this->executionTime, 'count' => $count]
            );

            $this->info("Done: {$count} reports");

        } catch (\Exception $e) {
            report($e);
            // No ping = MoniTao alert
            return 1;
        }
    }
}

The Laravel example uses the built-in HTTP client with automatic retry. Metrics (duration, item count) are sent with the ping for enriched monitoring. The exception stops the script before the ping.

Python

import requests
import sys
from datetime import datetime

PING_URL = "https://ping.monitao.com/p/YOUR_TOKEN"

def ping_monitao(duration_ms=None, status="success"):
    """Send ping to MoniTao with retry"""
    payload = {"status": status}
    if duration_ms:
        payload["duration"] = duration_ms

    for attempt in range(3):
        try:
            response = requests.post(
                PING_URL,
                json=payload,
                timeout=10
            )
            if response.ok:
                return True
        except requests.RequestException:
            continue
    return False

def main():
    start = datetime.now()
    try:
        # Your business logic
        process_data()
        sync_database()
        generate_reports()

        # Calculate duration and ping
        duration = (datetime.now() - start).total_seconds() * 1000
        ping_monitao(duration_ms=duration)
        print(f"Done in {duration:.0f}ms")

    except Exception as e:
        print(f"Error: {e}", file=sys.stderr)
        # No ping = alert
        sys.exit(1)

if __name__ == "__main__":
    main()

The Python script includes a reusable function with built-in retry. Execution duration is calculated and sent with the ping, allowing performance trend tracking in MoniTao history.

Node.js

const https = require('https');

const PING_URL = 'https://ping.monitao.com/p/YOUR_TOKEN';

async function pingMonitao(metrics = {}) {
    return new Promise((resolve) => {
        const data = JSON.stringify(metrics);
        const url = new URL(PING_URL);

        const req = https.request({
            hostname: url.hostname,
            path: url.pathname,
            method: 'POST',
            headers: {
                'Content-Type': 'application/json',
                'Content-Length': data.length
            },
            timeout: 10000
        }, (res) => resolve(res.statusCode < 400));

        req.on('error', () => resolve(false));
        req.write(data);
        req.end();
    });
}

async function main() {
    const start = Date.now();
    try {
        await processQueue();
        await syncData();

        const duration = Date.now() - start;
        await pingMonitao({ duration, items: processedCount });
        console.log(`Done in ${duration}ms`);

    } catch (error) {
        console.error('Error:', error.message);
        process.exit(1);
    }
}

main();

The Node.js example uses the native https module without external dependencies. The pingMonitao function returns a promise and can be easily integrated into any async/await script.

Implementation Best Practices

These recommendations will help you get the most out of heartbeat pings while avoiding common pitfalls.

• Ping at the end, not the beginning: The ping should always be the last action in your script, after all critical operations. Pinging at the beginning or middle gives false assurance: the job can fail after the ping without alerting you.
• Handle timeouts: Always add a timeout to your HTTP call (5-10 seconds). A network issue shouldn't block your main script. If the ping fails after retries, log the error but let the script complete normally.
• Use retries: A temporary network issue can cause ping failure. Configure 2-3 automatic retries with a short delay between attempts. This significantly improves reliability without significant duration impact.
• Send metrics: Use the ping to send useful data: execution duration, items processed, detailed status. These metrics enrich the history and allow detecting gradual degradations.
• Test the complete system: After integration, test the entire chain: run the script manually, verify the ping appears in MoniTao, then stop the script and verify the alert is received within the configured delay.

Common Mistakes to Avoid

These frequent mistakes can reduce your monitoring effectiveness or generate false alerts.

• Ping before validation: Pinging before verifying the result is dangerous. Your backup can create an empty file, your import can process 0 rows, your report can be corrupted. Validate the result before declaring success via ping.
• Ignoring "empty success": If your job does nothing when there's no data (0 emails to send, 0 files to process), you still need to ping. Otherwise, you can't distinguish "nothing to do" from "job didn't run". Ping to prove the job executed.
• Blocking synchronous ping: Without timeout, your script can hang indefinitely if the ping server doesn't respond. This can cause cascading delays or zombie processes. Always add a 5-10 second timeout.
• Grace period too short: If your job usually takes 5 minutes but can sometimes take 10, a 1-minute grace period will generate false alerts. Analyze your job variability and configure sufficient margin.

Concrete Use Cases

Heartbeat pings apply to many situations. Here are the most common cases with their implementation specifics.

Queue Workers

Workers processing queue messages (Redis, RabbitMQ, SQS) are ideal heartbeat candidates. A worker can die silently (OOM, crash, evicted container) without anyone noticing. Send a ping every 1-5 minutes in the worker's main loop. If the worker dies, pings stop and you're alerted before the queue dangerously fills up.

Backup Crons

Backups are critical but their failure is often silent: cron doesn't execute, script crashes, insufficient disk space. Create a daily heartbeat with 4-6 hour grace period. Ping after verifying backup integrity (non-empty file, valid checksum). You'll immediately know if a backup didn't happen.

Data Synchronizations

Synchronization jobs between systems (CRM ↔ ERP, database ↔ data warehouse) must run regularly to maintain consistency. An undetected sync stop causes divergences that accumulate and become expensive to fix. Ping after each successful sync cycle, including the number of synchronized records in metrics.

Heartbeat Ping with MoniTao

MoniTao simplifies heartbeat ping setup with an intuitive interface and advanced features for all your monitoring needs.

• One-click heartbeat creation with unique and secure ping URL
• Flexible configuration: intervals from 1 minute to 30 days, customizable grace period
• Receive and store metrics sent with each ping (duration, count, status)
• Complete ping history with trend graphs and anomaly detection

Frequently Asked Questions About Heartbeat Ping

Monitor All Your Processes with Heartbeat Ping

The heartbeat ping is a simple but extremely effective technique for monitoring processes that can't be tested from the outside. In just a few lines of code, you can transform any script, cron, or worker into a monitored process, with guaranteed alerts in case of unexpected shutdown.

With MoniTao, heartbeat ping integration takes less than 5 minutes. Create a heartbeat, copy the URL, add an HTTP call at the end of your script, and you're protected against silent failures. No longer discover your problems when it's too late - proactively monitor with heartbeat ping.

Ready to Sleep Soundly?

Start free, no credit card required.

Create My Account See pricing