Cron & scheduled jobs

An uptime check fails when a request fails. A scheduled job fails when nothing happens — and that is the harder failure to notice. A backup that silently stopped running looks exactly like a backup that is working, right up until the morning you need it.

How it works

Create a job on your dashboard and you get a ping URL. Call it when the job finishes:

0 3 * * *  /usr/local/bin/backup.sh && curl -fsS -m 10 https://…/p/YOUR_TOKEN

If a ping does not arrive within the job's period plus its grace, we record a missed run and alert you — through exactly the same channels, incidents and statistics as everything else.

Two details that matter

• Use &&, not ;. With a semicolon the ping fires even when the job failed, which is worse than no monitoring at all: you would be reassured by a broken backup.
• -fsS keeps curl silent on success and loud on failure, so a ping that cannot reach us shows up in your cron mail rather than vanishing.

Period and grace

The period is how often the job should run. The grace is how late it may be before we complain. A nightly backup that usually finishes at 03:02 should not page anybody at 03:00:01 — give it an hour of grace and sleep through the noise.

One missed run past its grace is the alert. There is no second threshold on top, because the grace period already is one.

Reporting a failure

A job that ran but failed should say so rather than staying silent:

./job.sh && curl -fsS $URL || curl -fsS -X POST --data "exit $?" $URL/fail

Anything you POST to /fail is kept as the run's note, so the alert tells you what went wrong instead of just that something did.

What we do not do

We do not run your jobs, and we cannot see inside them. We know only what your ping tells us: it finished, it failed, or it never arrived.