Cron Jobs Fail Quietly. Here’s the Monitoring Setup I’d Use First

Cron jobs fail in a different way than web pages.

A homepage failure is visible. A bad deploy breaks something a user can click. A failed background job can disappear quietly for days.

That is why heartbeat monitoring is one of the first checks I would set up for a small SaaS.

The short version

The point is not to monitor every internal detail. The point is to catch the quiet failures that would hurt trust if nobody noticed.

Why normal uptime checks are not enough

HTTP uptime monitoring asks: “Can I reach this URL?”

That works well for pages, APIs, login, and checkout flows. But scheduled jobs often do not expose a URL. They run from cron, a queue worker, GitHub Actions, Kubernetes CronJobs, serverless schedulers, or a background process.

If the job stops running, a normal uptime check may still stay green.

Examples:

• the website is up, but nightly backups stopped last week;


• the app works, but invoice generation skipped a run;


• the API is healthy, but the report email job is stuck;


• the dashboard loads, but the import that refreshes the data failed.

These failures are easy to miss because users rarely report them clearly. They just lose confidence.

How heartbeat monitoring works

Heartbeat monitoring flips the direction of the check.

Instead of a monitor asking your service “are you up?”, your job tells the monitor “I completed successfully.”

A basic setup looks like this:

1. Create a heartbeat monitor with an expected interval.


2. Give it a grace period.


3. Add one webhook call at the end of the job.


4. Alert if the ping does not arrive on time.

For a daily backup, that might mean:

• expected interval: every 24 hours;


• grace period: 60 minutes;


• ping timing: only after the backup completed and passed basic validation.

The last point matters. If you ping at job start, you only know the job started. If you ping after success, you know the useful work finished.

What I would monitor first

For an early-stage SaaS, I would start with a small list:

• one database backup job;


• one billing or subscription sync job, if relevant;


• one onboarding or transactional email job;


• one important data import/export job;


• one queue cleanup or scheduled maintenance job.

That is enough to catch the failures that can quietly damage trust without creating a noisy monitoring system.

A simple rule of thumb

Add a heartbeat when all three are true:

• the job runs on a schedule;


• the job matters to users or business operations;


• failure would not be obvious from the homepage being up.

If a job fails loudly already, you may not need a heartbeat yet. If a job fails silently and matters, add one.

Avoid these mistakes

Do not ping too early. Ping after success, not at the beginning.

Do not set the grace period too tight. A job that sometimes takes 35 minutes should not alert after 30 minutes.

Do not monitor every tiny task. Start with the jobs where silence is expensive.

Do not ignore recovery. An alert is only useful if someone knows what to check next.

The founder-friendly version

You do not need a heavy observability stack to start.

For the first version, a webhook heartbeat and a clear alert are usually enough:

# after the job succeeds

curl -fsS https://your-heartbeat-url.example/ping > /dev/null

Then document what the alert means:

• which job missed its heartbeat;


• when it last succeeded;


• what system owns it;


• what to check first;


• who should respond.

That turns a vague “something might be wrong” into an actionable reliability signal.

Related checklist

I wrote the original version of this topic here: Heartbeat Monitoring: How to Catch Silent Cron Job Failures.

If you are setting up monitoring for a small SaaS, I would pair heartbeat checks with uptime checks for your homepage, signup/login, and one critical user path. PingHarbor is built around that practical first layer of monitoring: website uptime, performance, and heartbeat monitoring.

If you want to try it, the signup path is here: start monitoring with PingHarbor.