New: Connect AI assistants via MCP

Core Concepts

Heartbeat Monitoring

Heartbeat Monitoring

Heartbeat monitoring is a push-based check — a "dead man's switch" for jobs that run on their own. Instead of us reaching out to a URL on a schedule, your job reaches out to us: it sends an HTTP request ("a ping") to a unique URL each time it finishes successfully. If an expected ping doesn't arrive in time, we open an incident and alert you, exactly as we would for a website going down.

It's the right check type for anything that runs in the background and produces no public endpoint to poll — the absence of a signal is the alert.

Use Cases

  • Backups & snapshots — know the first night a backup doesn't run, not when you need to restore
  • Queue workers & daemons — a periodic heartbeat proves the worker is actually processing, not just running
  • Scheduled tasks & ETL — nightly imports, report generation, cache warming and data syncs
  • Anything on a timer — if it should happen every N minutes/hours/days, a heartbeat catches a skipped run

How It Works

  1. Each heartbeat monitor gets a unique, unguessable ping URL
  2. You tell us how often the job should run (the expected interval) and how much lateness to tolerate (the grace period)
  3. Your job hits the ping URL when it finishes — we record the ping and schedule the next expected one
  4. If the expected interval plus the grace period elapse without a ping, we open an incident and notify you
  5. The next successful ping resolves the incident automatically

Setting Up a Heartbeat Monitor

  1. Click Add Monitor and select Heartbeat as the monitor type
  2. Give it a display name, choose the expected interval (e.g. every 5 minutes, hourly, daily) and a grace period
  3. Save the monitor — it stays in a pending state until its first ping arrives
  4. Copy the ping URL from the monitor's page and add it to the end of your job

Sending a Heartbeat

Hit the ping URL with any HTTP client when your job succeeds. GET, POST and HEAD are all accepted. The most common approach is to chain a curl after the job so it only fires on success: 

# crontab — only pings if backup.sh exits 0
0 3 * * *  /opt/backup.sh && curl -fsS https://your-domain/ping/your-token

To report a failed run and open an incident immediately, add ?status=fail: 

/opt/job.sh || curl -fsS "https://your-domain/ping/your-token?status=fail"

Notifications

A missed heartbeat is treated as a critical-tier incident — the same severity as a hard outage. It routes through whichever channels you have configured for the critical tier (email, SMS, Slack, webhook, in-app). The alert reads "Heartbeat Missed"; when a ping arrives again, a "Heartbeat Resumed" recovery notification fires and the incident closes.

Outbound Only

Heartbeat monitors are never probed from our side — there is nothing to open in your firewall and no agent to install. Your job makes a single outbound HTTPS request. Keep the ping URL secret; anyone who has it can mark the monitor as alive.

Notes & Limitations

  • Pending until first ping — a new monitor won't alert until it has received at least one ping to establish a baseline
  • No sub-checks — heartbeat is a push monitor; SSL, DNS and body assertions don't apply. Use an HTTP monitor for those
  • Plan-gated — heartbeat (and cron) monitoring is available on the Basic plan and above
  • For jobs on a fixed clock rather than a rolling interval, use Cron Job monitoring instead
Port MonitoringCron Job Monitoring