Monitor a cron job in 60 seconds

You do not need to change what your job does. You wrap it with two pings: one when it starts, one when it ends. That’s the entire integration.

Step 1: create a monitor

In the Cronitorex panel, create a ping monitor and give it a name, for example nightly-backup. Set the expected interval to however often the job should run (every 5 minutes, every hour, once a day) and a grace period on top of that for jobs whose runtime varies a bit. That’s the only setup step that happens in the panel; everything else lives in your crontab.

Step 2: wrap the command

Here is a typical crontab line for a nightly database backup, wrapped with three pings: one for run, one for complete on success, one for fail on a non-zero exit code.

# /etc/cron.d/nightly-backup
0 2 * * * root curl -fsS "https://api.cronitorex.com/ping/nightly-backup?status=run"; \
  pg_dump mydb | gzip > /backups/db-$(date +\%F).sql.gz \
  && curl -fsS "https://api.cronitorex.com/ping/nightly-backup?status=complete" \
  || curl -fsS "https://api.cronitorex.com/ping/nightly-backup?status=fail&exit_code=$?"

The semicolon after the run ping is deliberate: if the Cronitorex API is briefly unreachable, your backup still runs. Monitoring should never become a reason your job doesn’t execute.

If you’d rather not hand-write the wrapper, the cronitorex.sh client does it for you:

cronitorex run nightly-backup -- pg_dump mydb | gzip > /backups/db-$(date +%F).sql.gz

It sends the run ping, executes the command, captures the exit code and stderr automatically, and sends complete or fail for you.

Step 3: let a missed run alert on its own

This is the part that a plain curl at the end of a script cannot do: if the job never starts at all (crontab misconfigured, server rebooted and the cron daemon never came back, a deploy silently removed the entry), no ping ever arrives, in either direction. Cronitorex measures the gap since the last successful complete against the expected interval and grace period, and fires a missed alert when that window closes without one. You don’t have to write that logic yourself.

Step 4: pick where the alert goes

Set up at least one notification channel before you rely on this in production. Email works for a solo project; a shared Telegram or Discord channel works better for a team, since everyone sees the same alert at the same time without hunting through an inbox. All of these are available on every plan, including Free.

What you get out of it

A dashboard entry showing the last 30 runs at a glance, exit codes and stderr captured on failure so you’re not SSHing in to reconstruct what happened, and an alert that reaches you within about a minute of either a failure or a run that should have happened and didn’t. That last part, the missed run, is the one most homegrown monitoring setups miss entirely, because it requires watching for the absence of something rather than the presence of an error.