Cron Job Monitoring Tools Compared: From DIY to Fully Managed

Cron's biggest problem isn't scheduling — it's silence. A cron job can fail every night for a month, and unless you're manually checking logs on the server, you won't know. No alert, no dashboard, no audit trail. Just a backup that doesn't exist when you need it, or a data sync that quietly stopped three weeks ago.

Monitoring fixes this. But "cron job monitoring" means different things depending on the tool. Some watch for missing heartbeats. Some track full execution history. Some just page you when something breaks. This article compares six approaches — from writing your own monitoring scripts to using a fully managed scheduler with built-in observability — so you can pick the right one for your workload.

Heartbeat Monitoring vs. Execution Monitoring

Before comparing tools, understand the two fundamentally different approaches.

Heartbeat monitoring (dead man's switch) is passive. Your cron job pings a monitoring URL after each run. If the ping doesn't arrive on schedule, you get an alert. This tells you whether a job ran — but not what happened. If the job runs but returns bad data, the ping still fires and the monitor stays green.

Execution monitoring is active. The scheduler fires the job, captures the response, records the outcome, and alerts on failure. You get the full picture: status code, response body, duration, retry count, and a timeline of every execution.

When to use each: Heartbeat monitoring makes sense when you're stuck with system cron. Execution monitoring makes sense when you're choosing a scheduler — you get monitoring, retries, and logging as part of the platform.

Comparison at a Glance

Tool	Type	Alerts	Execution Logs	Retries	Free Tier
DIY scripts	Custom	⚠️ Whatever you build	⚠️ Whatever you build	⚠️ Whatever you build	✅ Free (your time)
Healthchecks.io	Heartbeat	✅ Email, Slack, webhooks	❌ No	❌ No	✅ 20 checks
Cronitor	Heartbeat + telemetry	✅ Email, Slack, PagerDuty	⚠️ Basic (duration, exit code)	❌ No	⚠️ 5 monitors
Better Stack	Uptime + heartbeat	✅ Email, Slack, PagerDuty	⚠️ Basic (heartbeat log)	❌ No	⚠️ 5 monitors
PagerDuty / Opsgenie	Incident mgmt	✅ Full escalation	❌ Requires integration	❌ No	⚠️ Limited
Runhooks	Execution (scheduler)	✅ Email, webhook	✅ Full (status, body, duration)	✅ Exponential backoff	✅ 3 jobs

DIY Monitoring

The simplest approach: wrap each cron job in a script that checks exit codes and sends alerts.

#!/bin/bash
/scripts/nightly-backup.sh >> /var/log/backup.log 2>&1
if [ $? -ne 0 ]; then
  curl -X POST https://hooks.slack.com/services/T00/B00/xxx \
    -d '{"text": "Backup job failed on prod-1"}'
fi

Pricing: Free in dollars, expensive in time.

Limitations: You're building monitoring for every job. No dashboard, no execution history, no retries unless you write them. When the server dies, the monitoring dies with it.

Best for: Solo developers with a handful of non-critical jobs.

Healthchecks.io

A dedicated heartbeat monitoring service. Create a check, get a ping URL, append it to your cron job. If the ping doesn't arrive on schedule, you get an alert. Supports start/success/fail signals so you can detect jobs that start but never finish.

Pricing: Free tier includes 20 checks with unlimited alert integrations. Paid plans start at $20/month.

Limitations: Doesn't execute your jobs — only watches for pings. No execution logs, no retries, no scheduling. If the job runs but produces bad results, the heartbeat still fires and the monitor stays green.

Best for: Teams using system cron or platform-native schedulers who need basic "is it running?" monitoring without changing their scheduler.

Cronitor

Heartbeat monitoring with added telemetry. Integrate via ping URLs or install the Cronitor CLI to automatically capture duration, exit code, and output size from your crontab entries.

Pricing: Free tier includes 5 monitors. Paid from $12.50/month.

Limitations: A monitoring layer, not a scheduler. Doesn't capture HTTP response bodies or provide retries. The CLI agent requires server installation — if the server dies, the agent dies with it.

Best for: Teams that want duration trends and exit code tracking beyond raw heartbeat pings.

Better Stack (formerly Better Uptime)

Primarily an uptime monitoring and incident management platform that includes heartbeat monitoring as a secondary feature. Your job pings a URL, Better Stack alerts if the ping is late — routed through on-call schedules and escalation policies.

Pricing: Free tier includes 5 monitors. Paid plans start at $24/month per user.

Limitations: Designed around uptime monitoring, not cron. No execution logs, retries, or scheduling. If you're only using it for cron monitoring, you're paying for functionality you don't need.

Best for: Teams already using Better Stack for uptime monitoring who want to add heartbeat checks without another tool.

PagerDuty / Opsgenie

Enterprise incident management platforms that don't monitor cron jobs directly — they're where cron alerts end up. Your monitoring tool fires an event on failure, and PagerDuty/Opsgenie handles routing, escalation, and acknowledgment.

Pricing: PagerDuty free tier covers 5 users. Paid from $21/user/month. Opsgenie starts at $9.45/user/month.

Limitations: These are alert destinations, not monitoring sources. You still need something to detect the failure. Adding PagerDuty is justified for enterprise on-call workflows but overkill for most cron monitoring needs.

Best for: Organizations with established on-call rotations that need cron alerts routed through existing incident management.

Runhooks Built-In Monitoring

Runhooks combines scheduling and monitoring into a single layer. The scheduler fires the HTTP request, inspects the response, logs the result, retries on failure, and alerts when retries are exhausted. There's no separate ping step — the scheduler is the monitor.

Every execution is recorded: HTTP status code, response body (up to 64 KB), duration in milliseconds, attempt number, and error details. Failed jobs enter a dead-letter state and trigger alerts via email or webhook.

Pricing: Free plan includes 5 jobs with retries and alerts. Paid plans add more jobs, longer log retention (up to 30 days), and higher retry limits. See full pricing.

Limitations: HTTP-only — if your job isn't callable via HTTP, you'd need to wrap it in an endpoint first. Natural fit for web services and serverless functions, less suited for legacy shell scripts.

Best for: Teams who want scheduling, retries, logging, and alerting in one tool without stitching together a monitoring stack.

Choosing the Right Approach

Locked into system cron? Add heartbeat monitoring. Healthchecks.io is the strongest option — generous free tier, simple integration, wide alert support.

Already use an observability platform? Check if it supports heartbeat checks (Better Stack, Datadog). No need for another tool.

Need to know why a job failed? You need execution-level monitoring — either extensive logging in every script (fragile) or a scheduler that captures execution details natively.

Scheduling HTTP endpoints? A managed HTTP scheduler like Runhooks gives you scheduling, retries, logs, and alerts in one layer. No heartbeat URLs, no wrapper scripts, no separate monitoring tool.

The monitoring gap in most cron setups isn't technical — it's organizational. Pick the approach that requires the least ongoing effort.

Get Started

If you're running scheduled HTTP jobs and want monitoring that's built into the scheduler rather than bolted on:

1. Create a Runhooks account — the free plan includes 5 jobs with retries and alerts
2. Test your cron expressions with the cron expression visualizer
3. Compare plans when you're ready to scale

Frequently Asked Questions

How do I know if my cron job stopped running?

You need external monitoring. Cron has no built-in failure detection. The two main approaches are heartbeat monitoring (your job pings a URL after each run — if the ping stops, you get an alert) and execution monitoring (the scheduler itself tracks every run and alerts on failures). Heartbeat tools like Healthchecks.io catch missing runs. Execution-aware schedulers like Runhooks catch missing runs, HTTP errors, timeouts, and retry exhaustion.

What is the difference between heartbeat monitoring and execution monitoring?

Heartbeat monitoring is passive — your cron job pings a URL when it completes, and the monitor alerts you if the ping is late or missing. Execution monitoring is active — the scheduler fires the job, inspects the response, and logs the outcome. Heartbeat monitoring tells you a job didn't run. Execution monitoring tells you why it failed, how long it took, and what the response was.

What is the best free cron job monitoring tool?

Healthchecks.io offers a generous free tier with 20 checks, and it handles basic heartbeat monitoring well. For execution-level monitoring with logs and retries, Runhooks includes a free plan with 5 jobs, automatic retries, and failure alerts. The best choice depends on whether you need passive heartbeat checks or active execution tracking.

Do I need cron monitoring if I already have uptime monitoring?

Yes. Uptime monitoring checks that your server responds to HTTP requests. Cron monitoring checks that scheduled tasks actually execute on time and succeed. A server can have 100% uptime while every cron job on it is silently failing — wrong permissions, expired credentials, full disk, or a killed cron daemon. These are different failure modes that require different monitoring.

---

Disclosure: I'm the founder of Runhooks, one of the tools compared in this article.