Your job pings a URL when it finishes. Silence past its deadline is a failure — and if you give okokumo the crontab line, the deadline follows the real schedule instead of a flat interval.
A cron job that crashes loudly gets noticed. A cron job that stops being scheduled — the crontab entry lost in a server migration, the container that no longer starts, the queue worker killed by the OOM reaper — produces no error, no email and no log line. It simply never runs again, and you find out when someone asks why the invoices did not go out.
Heartbeat monitoring inverts an HTTP check. Instead of okokumo polling your service, your job calls a unique ping URL after each successful run. Miss the window and okokumo raises the alarm, because the absence of a signal is the signal.
The simple form is a period and a grace delay: "expect a ping every hour, allow ten minutes of slack". That works until the schedule is not uniform.
0 3 * * 1-5 — 3am on weekdays — is 24 hours between Monday and Tuesday and 72 hours
between Friday and Monday. One flat interval cannot describe that. Set it to 24 hours and it
pages you every Saturday morning; set it to 72 and a job that silently stopped on Tuesday goes
unnoticed until Friday.
So a cron check can take the crontab expression itself, plus the IANA timezone your server's crontab runs in. The deadline becomes the next scheduled run plus the grace delay, recomputed after every ping. A weekday-only job stays quiet all weekend, and a skipped Tuesday run is caught inside its own grace window.
A crontab fires in its host's local time. A fixed UTC offset drifts by an hour at each daylight saving switch, and it drifts toward a false alert — 03:00 in Paris is 01:00 UTC in winter and 02:00 UTC in summer. Each check carries its own zone so servers in different regions do not have to agree.
The form lists the next few runs as you type, with each one's offset. A cron expression is easy to get subtly wrong — the day-of-month and day-of-week fields are OR'd, not AND'd, which surprises almost everyone once — and a wrong schedule here means a missed page rather than a cosmetic bug.
One HTTP request at the end of your job, from anything that can make one:
curl at the end of a shell script or a Docker entrypoint.Ping after the work succeeds, not at the top of the script. A job that starts, fails, and pings anyway is a job that reports healthy while doing nothing.
The minimum interval on your plan is checked against the tightest gap the expression
actually produces, sampled across its next fifty occurrences rather than reasoned about.
So * * * * * is refused on Free exactly as a 60-second interval is, and an
irregular schedule needs no special case.
Email, Telegram, Slack, Discord or a signed webhook; per-check routing or an organization default; a delivery log showing what was sent and what was skipped. How alerting works →