How to Set Up Heartbeat Uptime Monitoring

What is a Heartbeat Check?

A heartbeat check is the inverse of every other uptime check. Instead of Xitoring probing your service, your service pings Xitoring on a schedule. If the ping doesn't arrive within the expected window, Xitoring alerts you that the job stopped running.

This is the right tool for things you can't probe from the outside:

Cron jobs and scheduled tasks (backups, ETL, report generation)
Background workers and queue consumers
Daily/weekly scripts that run on a private server
Long-running batch jobs that should finish on a known cadence
IoT devices and edge agents that should check in periodically

For the marketing overview, see Heartbeat Monitoring.

What Gets Monitored

On-time arrival — heartbeat ping received within the configured period and grace window
Missed pings — alert when the next expected ping doesn't arrive
Last seen timestamp — track when each job last reported in
Per-job history — pings logged for audit and trend analysis

Prerequisites

A way for your job to make an outbound HTTPS request (e.g., curl, wget, language HTTP client)
Outbound connectivity to Xitoring's heartbeat endpoint from the host running the job
A defined expected period (how often the job runs) and grace window (how late is too late)

How to Set Up a Heartbeat Check

Step 1: Create the Heartbeat

Log in to your Xitoring Dashboard
Navigate to Heartbeats → Add Heartbeat
Give it a descriptive name (e.g., "Nightly Database Backup")

Step 2: Configure the Schedule

Set the expected period — how often the job should ping (e.g., every 24 hours)
Set the grace period — how long Xitoring waits after the deadline before alerting (e.g., 30 minutes)
Save to generate a unique heartbeat URL

Step 3: Add the Ping to Your Job

Append a request to the heartbeat URL at the end of your script, so Xitoring only hears about successful runs:

#!/bin/bash
set -e

# ... your job logic here ...
pg_dump mydb > /backups/mydb-$(date +%F).sql

# Notify Xitoring on success
curl -fsS --retry 3 https://<heartbeat-server>.xitoring.com/heartbeat/<your-heartbeat-id>

For cron, the same pattern works inline:

0 2 * * * /usr/local/bin/backup.sh && curl -fsS --retry 3 https://<heartbeat-server>.xitoring.com/heartbeat/<your-heartbeat-id>

Step 4: Assign Notifications

Under Triggers, attach a notification role so a missed heartbeat pages the right team.

Step 5: Run the Job and Verify

Trigger the job manually once. The dashboard should show the heartbeat as received within seconds.

Setting Up Triggers

Common alerting rules:

Missed heartbeat — no ping received within the expected period + grace window
Recovered — heartbeat resumes after a missed window (auto-resolves the incident)

Tips

Ping only on success — put the heartbeat call after set -e and after every step that could fail. A heartbeat from a failed job is worse than no heartbeat
Use --retry on the curl call — a transient network blip shouldn't trigger a false alert
Set a realistic grace window — long-running jobs vary in duration. Pad enough to absorb normal variance without burying real failures
One heartbeat per job, not per host — if a host runs five cron jobs, you want five heartbeats, each with its own schedule
Combine with logs — a missed heartbeat tells you something went wrong; the job's log tells you what
For very frequent jobs (every minute or two), batch into a watchdog that pings once per cycle to avoid overwhelming the dashboard with noise