Monitor a cron job with one curl command

Tenium App — Wed, 11 Nov 2026 16:20:20 +0000

Originally published on the Tenium blog. I am the author of Tenium, an uptime monitor for agencies.

The nightly backup has been failing for three weeks. Nobody knew, because a cron job that fails produces no error page, no red status and no customer complaint. It produces a restore attempt in month four that finds nothing.

The fix is small enough to fit in one line of your crontab. This guide shows the pattern, the variations for the platforms you probably use, and the mistakes that make a heartbeat monitor lie.

The idea: let the job check in

A normal uptime monitor asks your site “are you there?” A scheduled job has nothing to ask. The only signal is that it ran. So you reverse the direction: when the job finishes, it requests a URL. If that request does not arrive on time, the monitor alerts you.

Silence is the failure signal. That is why it catches jobs that never start.

Step 1: create the monitor

Create a heartbeat monitor. You get a URL of the form https://ping.tenium.app/h/<id>. The ID is the secret, so treat the URL like a password and keep it out of public repositories. Heartbeat monitors start on the Starter plan ($7 a month, 20 heartbeats); Pro includes 100 and Agency 500.

Choose how the schedule is expressed:

A period (every 15 minutes) for workers and queue consumers.
A cron expression with a time zone (0 3 * * *, Europe/Tallinn) for jobs that run at fixed times. If you are unsure about the expression, the cron expression builder reads it back in plain English and lists the next five runs.

Then set the grace time: the longest normal run plus a margin.

Step 2: add the line to your crontab

The smallest useful version:

0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 https://ping.tenium.app/h/abc123 > /dev/null

Three details in that line matter:

&& means curl runs only if the script exited with success. With ; you would report success for a failed job.
-m 10 --retry 3 stops a slow network from hanging the cron entry and retries a failed ping.
-fsS fails on HTTP errors, stays quiet on success and still prints errors, which cron mails to you.

To report failures right away instead of waiting for the grace window to run out:

0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 https://ping.tenium.app/h/abc123 || curl -fsS -m 10 https://ping.tenium.app/h/abc123/fail

Step 3 (better): wrap the job once

When you have ten jobs, copy-pasting that line gets messy. A small wrapper keeps it in one place and sends the exit code and the end of the output, which then appear in the incident:

#!/bin/sh
# usage: ping-wrap ID command args...
ID="$1"; shift
BASE="https://ping.tenium.app/h/$ID"
curl -fsS -m 10 "$BASE/start" > /dev/null
OUT=$("$@" 2>&1); CODE=$?
if [ "$CODE" -eq 0 ]; then
  curl -fsS -m 10 --retry 3 "$BASE" > /dev/null
else
  printf '%s' "$OUT" | tail -c 4000 | curl -fsS -m 10 --data-binary @- "$BASE/fail?exit=$CODE" > /dev/null
fi
exit "$CODE"

Use it as 0 3 * * * /usr/local/bin/ping-wrap abc123 /usr/local/bin/backup.sh. The /start call enables duration tracking: you see how long the job takes, and a job that starts but never finishes shows up as late.

Choosing the period and the grace

The two numbers decide how fast you hear about a problem and how often you are woken by nothing. Start from how the job really behaves, not from how it is meant to behave.

Job	Schedule	Grace	Why
Nightly database backup	`0 3 * * *`	45 minutes	Runs 10 to 25 minutes; month-end is slower
Queue worker heartbeat	every 5 minutes	5 minutes	One missed ping is a stuck worker, so be strict
Hourly import from a supplier	`15 * * * *`	20 minutes	The supplier’s API is sometimes slow
Weekly report e-mail	`0 7 * * 1`	2 hours	Waits for other jobs to finish first

Look at the last ten runs before you pick a grace: take the slowest, add half of it, and round up. Review it when the job gets slower.

Test it before you trust it

A monitor you have never seen fail is a guess. Test all three outcomes once, on a quiet afternoon:

Run the curl line by hand and check the monitor turns up with a fresh ping time.
Request the /fail URL by hand and confirm that the incident opens and the alert reaches the contact you actually read.
Comment the job out of the crontab, wait for the period plus the grace to pass, and confirm the “no ping” alert arrives. Then put the job back.

Write the monitor’s name and the job’s owner next to the crontab entry. In a year, nobody will remember which of twenty heartbeats belongs to which script.

Variations by platform

systemd timer. Add a line to the service unit:

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
ExecStartPost=/usr/bin/curl -fsS -m 10 https://ping.tenium.app/h/abc123

With Type=oneshot, ExecStartPost runs only after ExecStart finished successfully, so a failed job sends no ping.

Docker. Ping from the same shell command as the job, because a container that exits has no “after”:

docker run --rm myimage sh -c 'run-job && wget -q -O- https://ping.tenium.app/h/abc123'

Kubernetes CronJob. Add the ping as the last step of the container command, or run a second container in the pod that waits for the first. Keep the ID in a Secret, not in the manifest.

Windows Task Scheduler. As a PowerShell action: .\backup.ps1; if ($?) { Invoke-RestMethod https://ping.tenium.app/h/abc123 | Out-Null }.

WordPress. wp-cron runs only when somebody visits. The five WordPress checks post has a ready-made must-use plugin that pings on each scheduled run.

Mistakes that make a heartbeat lie

Pinging at the start only. You learn that the job began, not that it finished. Ping at the end, use /start as an extra.
; instead of &&. The ping goes out even though the script failed.
Pinging from a different place than the job runs. If the job is on server A and the cron ping is on server B, the monitor says nothing about A.
A grace period shorter than the worst run. Month-end runs are the slowest. Size the grace for them.
Time zone drift. A cron expression in the monitor must use the same zone as the server, including daylight saving changes.
Overlapping runs. A job that takes longer than its interval starts twice. Use flock -n /tmp/backup.lock in front of the script, and let the monitor tell you when runs are skipped.
Success that means nothing. A backup script that exits 0 after writing an empty file is a green light on a broken backup. Make the script check the output size, or run a restore test and ping only if it passes.

What to put in front of it

For every job that matters, the checklist is short: a heartbeat with a sensible grace, an alert contact you read (email on every plan, Telegram on paid plans), and a note of who owns the job. See cron job monitoring for the options, and the Tenium vs Cronitor comparison if cron and queue monitoring is your main requirement: Cronitor is built around exactly that, and the page says where it is stronger.

If you look after many client sites, Tenium has a free plan (20 monitors; heartbeats start on Starter): https://tenium.app

DEV Community: Tenium App