Heartbeat monitoring

Monitor cron jobs running on your own servers with heartbeat pings — detect missed, failed, and stuck runs. Declare monitors as code with YAML or Terraform.

A heartbeat check is a dead-man’s switch for a job running on your own infrastructure. Your job pings SteadyCron when it runs; if the ping doesn’t arrive on schedule, you get alerted before users notice.

This is ideal for nightly database backups, ETL pipelines, certificate renewals, log rotation, queue workers, and any cron you can’t (or don’t want to) move off your servers.

The ping URL

Each heartbeat check has a unique ping URL. Send an HTTP request to it from your job — from any language or shell. The simplest case is a single curl at the end of your script:

# your work here ...
curl -fsS https://ping.steadycron.com/<your-ping-token>

Ping types

You can send three kinds of ping to signal different points in a run:

  • /start — the job has started. Lets SteadyCron measure duration and detect runs that begin but never finish.
  • /success (the default, no suffix) — the job completed successfully.
  • /fail — the job ran but failed. Use this to alert on explicit errors, not just missing pings.
TOKEN=<your-ping-token>
curl -fsS https://ping.steadycron.com/$TOKEN/start
# ... run the job ...
if ./run-backup.sh; then
  curl -fsS https://ping.steadycron.com/$TOKEN
else
  curl -fsS https://ping.steadycron.com/$TOKEN/fail
fi

You can also include a short payload (e.g. a log tail) with the ping; it’s stored truncated for context in the activity feed.

Schedule and grace period

Tell SteadyCron how often the job should run — a cron expression or a simple interval — and set a grace period. The grace period absorbs normal variance (a backup that usually finishes at 02:05 but sometimes at 02:12). Once a ping is overdue beyond the grace period, the check is considered missed and an alert fires.

Detecting stuck runs

If you send a /start ping but no matching /success or /fail arrives within the expected window, SteadyCron flags the run as stuck (abandoned) — catching jobs that hang rather than fail outright.

Runbook notes

Attach a markdown runbook (and optional link) to the check — see Alerting → Runbook notes. When a heartbeat is missed or a /fail ping arrives, the runbook is embedded inline in the alert, so whoever’s on call gets the fix, not just “missed heartbeat.”

Status at a glance

Each check shows its current state: on time, late (overdue but within grace), missed, or failing. The dashboard surfaces failing checks first so problems are obvious.

Declaring monitors as code

Heartbeat monitors can be declared in a YAML manifest or as Terraform resources and committed to your repo alongside the jobs they watch. Both tools support the full set of options (schedule, grace period, alert rules) and the same plan / apply workflow you use for the rest of your infrastructure.

# steadycron.yaml
jobs:
  - id: nightly-db-backup
    kind: heartbeat
    schedule: "0 2 * * *"
    grace: 1800        # 30-minute grace period
    rules:
      - channel: ops-slack
        trigger: missed_heartbeat

# main.tf
resource "steadycron_heartbeat_monitor" "db_backup" {
  name            = "Nightly DB backup"
  key             = "nightly-db-backup"
  cron_expression = "0 2 * * *"
  grace_seconds   = 1800
}

See YAML & CLI or the Terraform provider for the full monitoring-as-code workflow.

Next steps