How to monitor cron jobs, and choose a grace period

Published 19 September 2026

A cron job that stops running rarely says so. The backup that last worked three weeks ago and the nightly import that died when a password rotated both fail without an error in front of anyone, because the thing that would have raised one never started. Checking from outside does not help either: there is nothing listening to check.

A heartbeat monitor turns it round. Your job calls InBrief each time it finishes, and when a call does not arrive in time, the job counts as failed and your team is told.

Wiring up a job

Saving a cron job monitor gives you a private check-in URL. It is shown once, so copy it then; you can rotate it later from the monitor. Add one request to the end of the job:

0 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 "YOUR-CHECK-IN-URL"

The && sends the check-in only when the job exits cleanly, so a failed run shows up as a missing one. -fsS keeps curl quiet unless something goes wrong, -m 10 stops a slow network from holding the job open, and --retry 3 covers a dropped connection. GET, HEAD and POST all work.

Reporting starts and failures

Two more addresses sit under the same URL. Call /start when the job begins and turn on runtime tracking, and a run that starts but never finishes is reported once it passes its maximum runtime. Call /fail when the job knows it has failed, and the monitor goes down straight away instead of waiting for the deadline.

#!/bin/sh
url="YOUR-CHECK-IN-URL"
curl -fsS -m 10 --retry 3 "$url/start" > /dev/null
if /usr/local/bin/backup.sh; then
  curl -fsS -m 10 --retry 3 "$url" > /dev/null
else
  curl -fsS -m 10 --retry 3 "$url/fail" > /dev/null
fi

Choosing the expected interval

Set Expected every to the job's schedule: five minutes for */5 * * * *, a day for a nightly job. The deadline runs from the last check-in rather than from the clock, so a job that starts at 02:00 and checks in at 02:07 is next expected at 02:07 the following night.

Choosing a grace period

The grace period is how late a check-in may be before the monitor counts as down. A monitor goes down once the expected interval and the grace period have both passed without a check-in.

Since the deadline runs from the last check-in, the grace period has to absorb variation: how much later one run can finish than the run before it. Runtime causes most of it. A job that checks in when it finishes checks in later on a slow night, so a backup that takes 20 minutes on a quiet night and 50 on a busy one can leave a gap 30 minutes longer than a day. A busy machine or a queue that starts jobs late adds more.

Measure the spread between your quickest and slowest normal runs, add a few minutes, and pick the next option up. Too short, and a slow but healthy night wakes somebody up. Too long, and a job that has really stopped is noticed late: the worst case is one full interval plus the grace period after the last good run.

Job	Expected every	Grace period
Queue worker that checks in every five minutes and finishes in seconds	5 minutes	1 minute
Hourly sync that takes between 2 and 10 minutes	1 hour	15 minutes
Nightly backup that takes between 20 and 50 minutes	1 day	1 hour

Runtime tracking catches a different failure, the job that started and hung. Set its maximum above your slowest normal run.

Before the first check-in

A new cron job monitor stays off your public status page until its first check-in arrives, so a job you are still wiring up never shows as an outage.