Home
Features
Heartbeat monitoring for cron jobs and background scripts

Heartbeat monitoring for cron jobs and background scripts

Q: What is the minimum period between pings?

The minimum period depends on the plan: Free — 5 minutes (300 seconds), Basic — 1 minute (60 seconds), Pro — 1 minute (60 seconds). These are the values from the plan matrix; shorter periods are not available — the minimum step on Basic and Pro is one minute. Grace adds a buffer on top of period during which a missing ping is not yet considered an alert. Realistic cron periods are 5 minutes to 24 hours.

Q: How do I get alerts only after N consecutive misses?

Each monitor has an alert_after_misses field — how many consecutive misses must occur before the monitor flips to down and dispatches a notification. A value of 1 means alert on the first miss (aggressive but noisy). A value of 2 or 3 means alert only after 2–3 misses in a row — protection against transient network flaps and one-off cron drops. For critical jobs (backups, billing) prefer 1; for noisy or known-flaky jobs prefer 2 or 3.

Q: How do I protect the ping endpoint from third parties?

Tracker.ru ships with optional two-factor protection: auth_mode=token_and_secret plus an X-Heartbeat-Secret header (constant-time compare on the Go worker). By default every monitor is created in token_only mode — the 32-character hex token is enough on its own: it cannot be guessed, and even if a third party learns it, all they can do is send an extra ping, which does not harm anything. The two-factor mode is for elevated security needs (for example, the monitor triggers a side-effect or the token lives in a public repository). Rate limit — 30 requests per minute per token.

Reverse monitoring for cron and background jobs: your script sends a ping to `https://hb.tracker.ru/ping/{token}` after each successful run, and Tracker.ru alerts you in Telegram, Email, MAX or webhook if the ping never arrives. Ready snippets for cron, systemd, GitHub Actions and Laravel scheduler. Included on every plan.

12 May 2026

Heartbeat monitoring in Tracker.ru is reverse monitoring for cron jobs and background scripts: your script sends a ping to our endpoint after each successful run, and if the ping never arrives, an alert is dispatched. It is the opposite of regular URL uptime monitoring: there, Tracker.ru pulls your site and inspects the response; here, your job pushes a heartbeat saying «I'm alive». You get ready snippets for cron, systemd timers, GitHub Actions and Laravel scheduler, and notifications in Telegram, Email, MAX or webhook when a scheduled job misses its ping. Detailed setup is in the documentation /docs/features/heartbeat-monitoring.

What is heartbeat monitoring and when do you need it?

Regular URL monitoring works pull-style: Tracker.ru sends an HTTP request to your site at a configured interval and inspects the response. That covers public pages and APIs but does not work for cron jobs: a 3 AM database backup has no public endpoint to poll. To verify that the job actually ran, you need push monitoring — the job itself notifies the service of a successful completion.

Heartbeat monitoring (also called dead-man's-switch or cron monitoring) does exactly that: you create a monitor in Tracker.ru, get a unique token and a URL of the form https://hb.tracker.ru/ping/{token}, and add a curl line to your cron command after the main action. If the job ran — the ping arrived, the monitor stays green. If the job crashed, didn't start, hung or lost connectivity — the ping is missed and Tracker.ru sends a notification through the channels you enabled (Telegram, Email, MAX, webhook).

Typical use cases: nightly database backups, S3 uploads and rsync jobs, ETL pipelines on Airflow or Dagster, queue workers (Laravel Horizon, Sidekiq, Celery), scheduled tasks from Laravel scheduler or Django celerybeat, scheduled GitHub Actions workflows, recurring business reports. For all of these, heartbeat monitoring directly answers the question «did my job run within the last 24 hours» without standing up a separate health endpoint or scraping cron logs.

How Tracker.ru monitors cron jobs through ping

The architecture is simple. A Go service apiServer runs on the hb.tracker.ru subdomain and accepts HTTP requests at GET https://hb.tracker.ru/ping/{token} (or POST for CI/CD scenarios with a body). The token is a 32-character hex string bound to a specific monitor in your account. The token doesn't have to be kept secret in most scenarios — even if a third party hits the ping URL, the only effect is an extra confirmation; nothing breaks.

You can attach a short message to the ping: ?msg=... in the query string or message=... in a POST body. The message is limited to 64 characters (Unicode runes, not bytes — that's up to 128 UTF-8 bytes for non-ASCII). The text lands in the monitor's last_ping_message field and is visible in /my/heartbeat/{id}. Useful for backup file names, hostnames, exit codes or job durations.

Key monitor settings: period (how often the job is expected to ping), grace (how long to wait beyond period before counting a miss) and alert_after_misses (how many consecutive misses before alerting — protection against single flaps). The minimum period depends on the plan: Free — 5 minutes (300 seconds), Basic — 1 minute (60 seconds), Pro — 1 minute (60 seconds). Realistic cron periods are 5 minutes to 24 hours; per-token rate limit is 30 requests per minute (a runaway script that pings every 100 ms will get HTTP 429 on the excess).

If period + grace elapses without a ping (after alert_after_misses consecutive misses), the monitor flips to down and notifications are dispatched. Full ping history and status changes are stored in /my/heartbeat/{id}, including average ping latency, 7-day uptime and last message text.

How to set up a heartbeat monitor in 3 steps

Connecting heartbeat monitoring to an existing cron job is a couple of minutes — no setup is required on the server side, only access to the Tracker.ru cabinet.

Step 1. Open /my/heartbeat, click «Create monitor». Fill in a name (for example, nightly-backup), pick the period between pings (1 hour or 1 day fits most cron jobs), optionally set grace and alert_after_misses. Enable the notification channels (Telegram, MAX, Email, webhook) — they pick up your global profile settings.

Step 2. Tracker.ru generates a token and shows a URL of the form https://hb.tracker.ru/ping/{token} (a 32-character hex token, unique per monitor). Copy this URL — you'll need it for the cron line.

Step 3. Add a curl after the main command in your cron job. The simplest bash form is && curl -fsSL https://hb.tracker.ru/ping/{token} — meaning «if the previous command exited with code 0, send the ping». If the main script fails, the ping is skipped, and after period + grace Tracker.ru sends a missed-ping alert.

Ready snippets for the four most common scenarios are below.

cron + bash. The most common case — a nightly backup or recurring report via crontab -e. The && curl only fires after a successful exit:

0 3 * * * /usr/local/bin/backup.sh && curl -fsSL https://hb.tracker.ru/ping/<token>

The -fsSL flags matter: -f suppresses HTTP error output, -s mutes the progress bar, -S keeps errors on stderr, -L follows redirects. If cron mails stderr, you won't get extra noise from curl.

systemd timer. On modern Linux servers, systemd timers often replace cron. The ping is added through ExecStartPost in the .service unit — it only fires when the main ExecStart returns exit code 0:

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
ExecStartPost=/usr/bin/curl -fsSL https://hb.tracker.ru/ping/<token>

The paired .timer unit holds the schedule (OnCalendar=daily), and the ping itself rides on the service unit. systemd already logs the exit code in journalctl, which makes post-incident analysis straightforward.

GitHub Actions. For scheduled workflows on GitHub Actions, store the token in secrets.TRACKER_PING_TOKEN and add the ping as the last step. If a previous step fails, GitHub's default behavior skips the next steps — the ping is not sent and Tracker.ru registers a miss:

on:
  schedule:
    - cron: '0 3 * * *'
jobs:
  backup:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/backup.sh
      - run: curl -fsSL https://hb.tracker.ru/ping/${{ secrets.TRACKER_PING_TOKEN }}

if: success() is the default — fine for heartbeat. Don't use if: always(): it would send the ping even on failure, defeating the purpose.

Laravel scheduler. In Laravel projects, use the built-in scheduler with the ->onSuccess() or ->after() hook — it runs only after a successful command:

$schedule
    ->command('backup:run')
    ->daily()
    ->onSuccess(fn () => Http::get(config('services.tracker.ping_url')));

Put tracker.ping_url in config/services.php with the value https://hb.tracker.ru/ping/{token} (loaded via .env). On success, the scheduler fires the ping; on failure, it doesn't.

The same pattern works for supervisord (event listener for PROCESS_STATE_RUNNING), Airflow (on_success_callback), Sidekiq, Celery and other job runners. More examples with error handling are in the documentation.

How does Tracker.ru compare to focused cron-monitoring services?

There are focused SaaS services in this niche that only do cron monitoring. For some teams those fit better; for others, having heartbeat as part of a broader uptime platform is more convenient. Honest framing — by the facts, no agitation.

healthchecks.io is an open-source SaaS for cron monitoring. Confirmed: focus is cron jobs, scheduled tasks and server health checks; UI and docs are in English; billing is in USD (free plan plus paid tiers from $5 to $80/month); the source code is BSD-3 on GitHub (healthchecks/healthchecks), with a documented self-hosted Docker option. If you only need cron monitoring and a USD-billing English-UI SaaS or a self-hosted instance fits your stack — healthchecks.io is a strong choice.

cronitor.io is a focused SaaS for cron job monitoring. USD billing, English UI. A reasonable choice for teams already on Western SaaS who don't mind paying in USD for a single-purpose product.

What Tracker.ru does differently. Heartbeat is not a separate product — it's part of a broader uptime platform. One subscription includes URL monitoring from three regions (Russia, EU, Kazakhstan), SSL monitoring with expiry alerts, screenshot monitoring with pixel diff, maintenance windows, plus heartbeat on the same plans. Billing is in rubles, support is in Russian, the UI is in Russian by default with English available. Convenient when you already have one site plus a few cron jobs and don't want two services with two billings. If your only need is cron monitoring — the focused alternatives above will likely suit you better.

Create a heartbeat monitor

Frequently asked questions

How much does heartbeat monitoring cost?

Heartbeat is included on every Tracker.ru plan, no separate fee. Free includes 1 heartbeat monitor (enough for one pet project or a personal backup), Basic — 5 monitors, Pro — 20. The limit is the number of concurrent active monitors, not pings per day: within a single monitor you can send as many pings as you like, capped by the rate limit of 30 requests per minute per token (protection against a runaway script).

What is the minimum period between pings?

The minimum period depends on the plan: Free — 5 minutes (300 seconds), Basic — 1 minute (60 seconds), Pro — 1 minute (60 seconds). These are the values from the plan matrix; shorter periods are not available — the minimum step on Basic and Pro is one minute. grace adds a buffer on top of period during which a missing ping is not yet considered an alert. Realistic cron periods are 5 minutes to 24 hours: backups usually once a day, queue cleanup once an hour, recurring reports a few times a day.

How do I get alerts only after N consecutive misses?

The monitor has an alert_after_misses field — how many consecutive misses must occur before the monitor flips to down and dispatches a notification. A value of 1 means «alert on the first miss» (aggressive but noisy). A value of 2 or 3 means «alert only after 2–3 misses in a row» — protection against transient network flaps and one-off cron drops. For critical jobs (backups, billing) prefer 1; for noisy or known-flaky jobs prefer 2 or 3.

How do I protect the ping endpoint from third parties?

Tracker.ru ships with optional two-factor protection: auth_mode='token_and_secret' plus an X-Heartbeat-Secret header (constant-time comparison on the Go worker). By default every monitor is created in token_only mode — the 32-character hex token is enough on its own: it can't be guessed, and even if a third party learns it, all they can do is send an extra ping, which doesn't harm anything. The two-factor mode is for elevated security needs (for example, if the monitor triggers a side-effect in your infrastructure or the token lives in a public repository). Enable it in the monitor settings, store the secret separately, send it in the header: curl -H 'X-Heartbeat-Secret: <secret>' https://hb.tracker.ru/ping/<token>. The rate limit of 30 requests per minute per token applies in both modes.