Know before data loss happens — monitor every backup job
Backup jobs are your last line of defense. When a script silently fails or misses its window, you don't find out until you need to restore — and by then it's too late. Cronping pings your backups on completion and alerts you the moment anything goes wrong.
#!/bin/bash
# ... your backup logic ...
mysqldump -u root mydb | gzip > /backups/mydb_$(date +%F).sql.gz
# Ping Cronping on success
curl -fsS https://ping.cronping.com/YOUR_TOKEN > /dev/null
# Or signal failure explicitly
# curl -fsS https://ping.cronping.com/YOUR_TOKEN/fail > /dev/nullOne line added to your script. Cronping handles the rest.
The cost of silent failures
Silent script failures
Your script exits 0 but the backup file is empty or corrupt. The job looks fine in cron logs. No one knows until a restore is needed.
Missed backup windows
The job never ran. Cron restarted, the server rebooted, or the process was killed. No notification, no trace.
No visibility on remote servers
Backups run on VMs, containers, or managed databases with no log aggregation. You're relying on the job to tell you it worked — but jobs don't talk.
Discovery at the worst moment
You only find out the backup failed when you actually need to restore. Hours or days of data loss, missed SLAs, and a very bad day.
Set up in under 2 minutes
- 1
Create a heartbeat
Set up a heartbeat in Cronping with your backup schedule — e.g., "Daily at 02:00 UTC". Give it a name like "Production DB Backup".
- 2
Add one line to your script
Call the Cronping ping URL at the end of your backup script. If the script is interrupted or fails before reaching it, the ping never happens.
- 3
Get alerted immediately
If the backup misses its window or the script doesn't complete, Cronping alerts your team via Slack, email, PagerDuty, or any channel you choose.
Everything you need
No SDK, no dashboard agent, no infrastructure to manage.
Grace periods
Allow for variable backup durations. Set a window of minutes or hours before Cronping considers the job late.
Explicit failure signaling
Use /fail to explicitly signal a backup error. Get separate alerts for "job never ran" vs "job ran but failed".
90-day run history
Visual timeline of every backup run — when it started, how long it took, and whether it succeeded. Instant audit trail.
Multi-channel alerts
Email, Slack, Discord, PagerDuty, Microsoft Teams, Telegram, custom webhooks. Alert whoever needs to know.
Flexible cron schedules
Full cron expression support with timezone awareness. Monitor weekly, nightly, or hourly backups with the same tool.
Team notifications
Route alerts to the right people — DBA team, on-call engineer, or a dedicated backup-alerts channel.
Frequently asked questions
Add `curl -fsS https://ping.cronping.com/YOUR_TOKEN > /dev/null` at the end of your backup script. If the dump fails or the script is interrupted before reaching that line, the ping never happens and Cronping alerts you after the grace period expires.
Set a grace period in Cronping (e.g., 2 hours). The heartbeat will only alert you if the backup hasn't completed within the expected window plus the grace period. No false alarms for slow-running jobs.
Yes. Any backup tool that runs a shell script or scheduled command can be monitored. Just call the Cronping ping URL at the end of the process. If the tool supports post-job hooks, use those instead.
Yes. Use the base URL for successful completion and append /fail for explicit failures. You can also use /start when the backup begins to track run duration.
Your server needs outbound HTTPS access to ping.cronping.com. Most production servers allow outbound HTTPS. If yours doesn't, you can route the ping through a proxy or bastion host.
Stop discovering failures when it's too late.
Free to start. No credit card required. Add your first heartbeat in under 5 minutes.