A passing cron job is not a working backup.
cron tells you a command exited 0. It doesn’t check that restic wrote a snapshot, that the dump isn’t empty, or that the job still runs at all. backpulse wraps the command you already run with the backupctl CLI, checks the result, and alerts you when something’s off.
Alerts over email, Slack, Telegram, and webhooks. Install the OSS backupctl CLI →
The problem
Your cron is green. Your backup is gone.
cron only knows whether a command started and how it exited. It has no idea the snapshot came out empty, the restore is broken, or the job quietly stopped running after a host reboot. You tend to find out during the restore, which is the worst time to find out.
How it works
One line in front of the command you already run
Wrap the command
Put backupctl in front of the restic, borg, rclone, or pg_dump command your cron already runs. No agent, no sidecar, nothing to migrate.
It checks the result
When the command exits, backupctl looks at what it actually produced: a recent snapshot, non-empty, that restores cleanly. Then it pings backpulse with the outcome.
You hear about it when it breaks
Miss a ping, report a failure, or run past your window, and backpulse alerts you over email, Slack, Telegram, or a webhook.
# whatever comes after -- is the command your cron already runs
backupctl run --url https://api.backpulse.io --key <key> -- restic backup /data
# checks the snapshot, then pings backpulse: ok or failedWhat it catches
How a backup stops working without anyone noticing
Didn’t run
The cron line got removed, the box rebooted, or someone disabled it “for a minute” back in March. Nothing runs, and nothing says so.
Failed
Non-zero exit, killed mid-write, disk full. backupctl reports it instead of leaving it in a log nobody opens.
Ran late
It started hours after its window. You set the schedule; backpulse notices when the ping shows up late.
Ran too long
restic stuck on a lock, rclone throttled, a pg_dump that never returns. You hear about it before the next run stacks on top of it.
Ran twice
Two overlapping runs, a retry loop, a duplicate cron entry on a second host. Usually worth a look.
Backed up nothing
The job is green but the snapshot is a week old, zero bytes, or won’t restore. backupctl checks age, size, and whether a restore actually works.
k8s CronJob & CI
Missed schedules, failed Jobs, a red pipeline that was quietly doing your exports. Same check-in for cron, Kubernetes, and CI.
And the one weird failure mode specific to your setup. Tell us about it on the form. Sorting those out is what the beta is for.
Why backpulse
Always know where your last good backup is
For each backup, three plain facts: the last run that worked, the last checked restore, and the next run due. “Are our backups fine?” stops being a guess you make during an incident.
- Last good backup
- The most recent snapshot that’s fresh, non-empty, and passed its checks.
- Last checked restore
- When a restore was last verified, not the last time someone assumed it was.
- Next expected run
- When the next ping is due, and an alert if it doesn’t arrive.
Would you pay $15/month to trust your backups?
Record a real paid-beta commitment. Nothing is charged today; we confirm fit and billing before your beta starts. Or run the open-source backupctl CLI now.
FAQ
What does the paid-beta commitment mean?
You state that you intend to subscribe at $15/month if accepted into the backup-verification beta. Nothing is charged today. We confirm fit and billing with you before the beta starts.
What do I need to use it?
A backup command you already run (restic, borg, rclone, pg_dump, whatever), something that runs it on a schedule (cron, a Kubernetes CronJob, CI), and somewhere to get alerts (email, Slack, Telegram, a webhook).
Is there a self-hosted option?
backupctl is open source and runs on your own machines; it only sends small status pings out. The hosted receiver and alerting service is the paid product being validated. Mention self-hosting needs in the form.