Skip to content
use-cases / heartbeat-for-silent-jobs / hero
CRON · NOTIFICATIONS · SILENCE-ALARM

A heartbeat for the silent jobs

Most monitoring watches what happened. You needed something that watches what didn't. Two cron entries — one beats, one listens for the absence of a beat — and the page that finds you on a beach.

Read the cron docs
use-cases / heartbeat-for-silent-jobs / mechanism

Two cron entries. One says I'm alive. The other listens for nothing.

The job you already had keeps doing its work. After it finishes, it adds one curl: a heartbeat row to a notifications endpoint. A second cron entry runs on its own cadence and checks for silence — if no fresh beat, it pages your phone. The job's success is silent. Its absence is loud.

worker.cron · the job
POST · heartbeat
schedule0 2 * * *
# After the nightly export finishes,# the job pings its own heartbeat.0 2 * * * /usr/local/bin/export.sh \ && curl -fsS -X POST \ https://notify.containers.hoody.com/heartbeats/backup-prod-db
the absence is the signal
watcher.cron · the listener
GET · silence-check
schedule*/15 * * * *
# Every 15 minutes, ask: was there a beat?# If silent for >1h, the API pages all channels.*/15 * * * * curl -fsS \ https://notify.containers.hoody.com/silence-check?\ job=backup-prod-db&max_age=1h

Two POSTs to /users/root/entries with five-field expressions. The first runs after each scheduled job and posts its heartbeat. The second runs on its own cadence, asks the notifications endpoint whether the last beat is fresh enough, and triggers the page if not. No queue, no agent, no daemon — just two crontab lines that already had to exist.

use-cases / heartbeat-for-silent-jobs / powers

Why watching absence is different

Most monitoring tools watch the success path: they alert when something happens. This shape alerts when nothing does — and that's the case the silent jobs always lose.

FAILURE MODES

Catches the silent crash

If the worker process never starts — the box rebooted, the script was deleted, a quota expired — there is nothing to log and nothing to alert on. The watcher cron runs anyway and notices that the heartbeat row is stale. The thing that catches the silent crash is exactly the thing that doesn't depend on the silent thing.

ZERO SURFACE

No new service to babysit

The monitor is one extra crontab line, not a Healthchecks.io account or a CloudWatch alarm. It's bound to the same container as the work, expires with `expires_at` if you want it to, and reads from the same notifications API the rest of your stack already uses.

REACHES YOU

Loud when it matters

The notifications endpoint fans the page across push, SMS, and email — the channels you already trust. You don't watch the dashboard. The dashboard watches itself, and finds you on the beach in Bali only when the silence has gone on too long.

use-cases / heartbeat-for-silent-jobs / capacity

Real cron, real notifications

The mechanism is plain Hoody Cron and Hoody Notifications. The numbers come from the documented API surface, not from a demo runtime.

  1. ALL CRON SYNTAX@daily

    Standard 5-field expressions plus macros — `@hourly`, `@daily`, `@weekly`, `@monthly`, `@yearly`. The watcher and the worker can have completely different cadences.

  2. AUTO-EXPIRYexpires_at

    Managed entries support `expires_at`, so a temporary heartbeat (a one-week migration window, say) cleans itself up. The watcher disappears with the work.

  3. ISOLATIONper-user

    Each container gets its own crontab. The heartbeat for one tenant cannot mute the watcher for another, and disabling a job is a single PATCH `enabled: false`.

Limits per the Hoody Cron API: 5-field expressions plus the `@hourly`/`@daily`/`@weekly`/`@monthly`/`@yearly` macros, optional `expires_at` on managed entries, per-user crontab isolation, enable/disable via PATCH.

use-cases / heartbeat-for-silent-jobs / punchline

Silence is now an alert.

BEFORE · WATCHING THE LOGopen dashboard · search for last export · sigh · forgetyou only notice the missing job on Monday
AFTER · WATCHING THE QUIET*/15 * * * * curl /silence-check?job=backup-prod-dbthe page reaches you while the silence is still small
Read the cron docs
use-cases / heartbeat-for-silent-jobs / replaces

What this replaces

The standard reach-for-it tools when you want a cron-monitor with paging. Each one is a separate account, a separate bill, a separate API. Two crontab lines and the notifications endpoint do the same job.

  • custom orchestratorsWhole orchestration services for what is two crontab lines
  • Healthchecks.ioA SaaS account just to receive an HTTP heartbeat
  • CronitorPer-monitor pricing for a thing your container already does
  • Dead Man's SnitchThe exact pattern, sold as a subscription
  • AWS CloudWatch alarms for cronLambda + alarms + IAM policies for one stale row
  • custom heartbeat collection scriptsA microservice to log a value the cron could just POST
use-cases / heartbeat-for-silent-jobs / cta

Stop watching the success path. Watch the absence of success — it's the only place the silent failures live.

Read the cron docs
use-cases / heartbeat-for-silent-jobs / related

Read the others