Silent cron job failures, solved
The backup ran for the last time three weeks ago. The nightly report never fired. The cleanup job is stuck and nobody noticed. Cron jobs fail without making noise — Cronping makes them check in on schedule, and alerts you the moment one doesn't.
# Before: no visibility
0 2 * * * /scripts/run-backup.sh
# After: one curl at the end
0 2 * * * /scripts/run-backup.sh && curl -fsS https://ping.cronping.com/YOUR_TOKEN > /dev/null
# Or wrap with start + fail signals for full visibility
0 2 * * * curl -fsS https://ping.cronping.com/YOUR_TOKEN/start && /scripts/run-backup.sh && curl -fsS https://ping.cronping.com/YOUR_TOKEN || curl -fsS https://ping.cronping.com/YOUR_TOKEN/failOne line added to your script. Cronping handles the rest.
The cost of silent failures
Jobs that never started
The server rebooted and cron never came back up. A deployment wiped the crontab. The container restarted without the scheduler. No error. No trace. Nothing.
Failures discovered by users
The weekly report didn't arrive. The invoice wasn't generated. The cache wasn't warmed. You find out when a customer asks, not when the job fails.
Jobs that hang indefinitely
A database query locks up. An HTTP call never times out. The job is technically running but doing nothing — and it blocks every scheduled run after it.
No central visibility
Jobs are scattered across VMs, containers, Lambda functions, and GitHub Actions. There's no single place to see what ran, what failed, and what's overdue.
Set up in under 2 minutes
- 1
Create a heartbeat
Set up a heartbeat in Cronping with your job's schedule — cron expression or plain interval. Give it a name and a grace period.
- 2
Add one line to your job
Call the ping URL at the end of your script with curl, wget, or any HTTP client. If the job fails or never runs, the ping never fires.
- 3
Get alerted instantly
When a job misses its window, Cronping alerts your team via Slack, email, PagerDuty, or any channel you've configured. No polling, no log scanning.
Everything you need
No SDK, no dashboard agent, no infrastructure to manage.
Dead man's switch pattern
If the ping doesn't arrive within the expected window, something went wrong. Catches every failure mode: script crash, missed execution, hung process, or scheduler death.
Start and fail signals
Use /start to signal job begin and /fail for explicit errors. Track exact duration per run and get immediate alerts on failure — no waiting for the grace period.
Grace periods
Set a window of extra time before a late job triggers an alert. Handles variable-duration jobs without false positives.
90-day run history
Visual timeline of every execution: when it ran, how long it took, and whether it succeeded. Identify patterns before they become incidents.
Multi-channel alerts
Slack, email, Discord, PagerDuty, Microsoft Teams, Telegram, webhooks. Route critical job failures to whoever needs to know.
Works anywhere
Bash, Python, Node.js, Ruby, PHP, Go, Kubernetes CronJobs, GitHub Actions, AWS Lambda, Vercel Cron. Any job that can make an HTTP call can be monitored.
Frequently asked questions
Logs tell you what happened when a job ran. They don't tell you when a job never ran at all. If the scheduler dies, the crontab is removed, or the server reboots, there's nothing to log. Dead man's switch monitoring detects the absence of a signal — which is the only reliable way to catch missing executions.
You'll need outbound HTTPS access to ping.cronping.com on port 443. Most production environments allow this. If yours doesn't, you can route the ping through a proxy, bastion host, or internal forwarding service.
Yes. Cronping handles high-frequency schedules well. For jobs running every 1–5 minutes, each ping resets the timer. If any single execution misses, you'll be alerted after the grace period.
Any platform that can make an HTTP GET request. Bash with curl, Python with requests or urllib, Node.js with fetch or axios, Ruby, PHP, Go, .NET, and more. Cronping also works with Kubernetes CronJobs, GitHub Actions, AWS Lambda, and Vercel Cron.
Yes. POST a JSON payload to include metrics like rows processed, bytes written, or duration. You can configure alert rules based on payload values — for example, alert if rows_processed equals 0.
If at least one instance should run, use the same ping URL on all servers. Cronping considers the heartbeat healthy as long as any instance pings within the window. If you need exactly one instance to run, handle that at the scheduler level.
Stop discovering failures when it's too late.
Free to start. No credit card required. Add your first heartbeat in under 5 minutes.