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 HelloCron 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
HELLOCRON_API_KEY=your_api_key
HC=https://api.hellocron.com/ping/nightly-backup

0 2 * * * root curl -fsS -H "Authorization: Bearer $HELLOCRON_API_KEY" "$HC?status=run"; pg_dump mydb | gzip > /backups/db-$(date +\%F).sql.gz && curl -fsS -H "Authorization: Bearer $HELLOCRON_API_KEY" "$HC?status=complete" || curl -fsS -H "Authorization: Bearer $HELLOCRON_API_KEY" "$HC?status=fail&exit_code=$?"

Yes, the entry is one long line. Cron does not support line continuations, so a backslash at the end of a line does not join it with the next one. The two variables at the top keep the line readable: cron passes them to the command’s environment, and the shell expands them when the job runs.

The semicolon after the run ping is deliberate: if the HelloCron 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 hellocron.sh client does it for you:

0 2 * * * root /usr/local/bin/hellocron run nightly-backup /bin/sh -c 'pg_dump mydb | gzip > /backups/db-$(date +\%F).sql.gz'

The API key comes from the client’s config file (hellocron configure), so it does not appear in the crontab. The pipe and the redirect sit inside sh -c '...' on purpose: without it, the shell would apply them to the output of hellocron itself, and only pg_dump would be monitored.

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. HelloCron 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.