Silent cron failures: why your scheduled jobs need a heartbeat

Most outages announce themselves. A website returns a 500, an API times out, a dashboard goes blank — something responds, and monitoring catches it. Scheduled jobs are different. When a nightly backup, a billing run, or an inventory sync fails to execute, nothing responds at all. There’s no error to catch, because there’s no request. The job simply doesn’t happen — and you find out days later, when the damage is already done.

This is the trap of the silent failure, and it’s exactly what heartbeat monitoring exists to solve.

Why traditional monitoring misses cron jobs

Uptime monitoring works by checking something that should respond. You point it at a URL or a host, it sends a request, and it alerts you if the response is wrong or missing.

A cron job has nothing to check. It has no public URL. It runs on a schedule, does its work, and exits. If the server was overloaded, the container never started, a deploy broke the schedule, or the script died halfway — the job just doesn’t run, and there’s nothing for a monitor to poll.

The result: your most business-critical automation is often your least-monitored.

The heartbeat model: watch for silence

Heartbeat monitoring flips the direction. Instead of Spectra checking your job, your job checks in with Spectra.

1. You create a heartbeat and get a unique URL.
2. Your job calls that URL when it finishes successfully — one line of curl at the end of the script.
3. Spectra expects that ping within a window you define (the schedule plus a grace period).
4. If the ping doesn’t arrive in time, the job is overdue — and Spectra alerts you.

No agent, no SDK, no inbound access to your infrastructure. If your job can make an HTTP request, it can send a heartbeat.

# at the end of your nightly backup
0 3 * * * /usr/bin/backup.sh && curl -fsS https://spectrabolt.com/beat/8f2a-91c4

Beyond “did it run?”

A good heartbeat tells you more than pass or fail:

• Missed run — no ping arrived in the window. The job never ran.
• Late run — the ping arrived, but outside the grace period. Something is slowing down.
• Failure ping — the job ran but reported an error by pinging a /fail endpoint from its error handler.
• Ran too long — the gap between a start ping and a completion ping exceeded your maximum, catching jobs that hang.

Those distinctions matter. A backup that finishes 40 minutes late every night isn’t “up” — it’s a warning that you’re one bad night away from a missed window.

What to put a heartbeat on

If it runs on a schedule and matters, monitor it:

• Database and file backups
• Billing and invoicing runs
• Report and digest-email generation
• ETL / data-sync pipelines
• Queue workers that should never go quiet
• Certificate renewals and cleanup jobs

The bottom line

Silent failures are dangerous precisely because they’re silent. The fix isn’t more dashboards — it’s inverting the check so that absence becomes a signal. Add one line to your job, define the window, and let the silence trigger the alert.

Ready to catch the jobs that fail quietly? Explore heartbeat & cron monitoring →