Vivere / Answers

borgmatic says 'cronhub' was unexpected, or its Cronhub hook stopped working

Cronhub shut down in mid-2026 and borgmatic removed its Cronhub hook in 2.1.7, so a leftover cronhub: section either stops borgmatic loading that config or quietly pings nothing.

borgmatic used to ship a Cronhub hook: a cronhub: section with a ping URL, which borgmatic called when a backup started, finished or failed. Cronhub shut down in mid-2026, and borgmatic removed the hook in version 2.1.7, released in August 2026, noting it as a breaking change. What you see now depends on which borgmatic you run (borgmatic --version).

borgmatic 2.1.7 or later: the config doesn't load

borgmatic's configuration schema rejects options it doesn't know, and cronhub is no longer one of them. So after an upgrade, a config file that still has the section fails like this:

/etc/borgmatic/config.yaml: Error parsing configuration file
An error occurred while parsing a configuration file at /etc/borgmatic/config.yaml:
At the top level: Additional properties are not allowed ('cronhub' was unexpected)

borgmatic skips that whole file. Nothing in it runs: no create, no prune, no check, and no other monitoring hook in the same file pings either, because the file never loaded. If it is your only config, every scheduled run since the upgrade has exited with an error and no backup. Whether anyone noticed depends on whether cron mails you or the systemd unit's failure goes anywhere you read.

borgmatic 2.1.6 or earlier: it runs, and nothing is watching

Older versions, including some that distributions still package, keep the hook. Each start, finish and fail ping waits up to 10 seconds for cronhub.io and then logs a warning such as Cronhub error: ... Read timed out, and the backup carries on. borgmatic treats a monitoring failure as a warning on purpose, so a dead monitoring service never blocks a backup. The backups still run, but a night they don't will go unnoticed, which is what the hook was there to catch.

The fix: delete the section and choose a new monitor

First remove the cronhub: section and check the file:

borgmatic config validate

Then put a monitor back, because the reason you added Cronhub hasn't gone away. borgmatic 2.2 has hooks for Healthchecks, Cronitor, Uptime Kuma, ntfy, PagerDuty, Pushover, Zabbix, Apprise, Loki, Sentry and Watchgoose (checked November 2026). The closest to what the Cronhub hook did is the Healthchecks hook: it pings on start, on finish and on failure, so a failed backup alerts at once and one that never starts alerts when it is overdue.

Before:

cronhub:
    ping_url: https://cronhub.io/ping/<your-uuid>

After:

healthchecks:
    ping_url: https://hc-ping.com/<your-check-uuid>
    send_logs: true

The URL can be Healthchecks.io's, your own Healthchecks server's, or any service that takes Healthchecks-style ping URLs. send_logs attaches the tail of borgmatic's log to the finish and fail pings, which is the fastest way to see why a run failed; it has been off by default since borgmatic 2.1.0. To ping only for some states, add states: [start, finish, fail] or a subset.

Give the new check the same schedule as the borgmatic timer or cron entry, with a grace period longer than your slowest backup, then run one backup by hand and watch the start and success pings arrive before you trust it:

borgmatic create --verbosity 1

Or point it at Vivere

Ours. Vivere's ping URLs take the same forms as Healthchecks.io's, so the same hook works with the monitor's URL:

healthchecks:
    ping_url: https://vivere.dev/p/<your-monitor-id>
    send_logs: true
    ping_body_limit: 65536

Vivere keeps the last 64 KB of each ping, which is what ping_body_limit matches. It is free for 25 monitors with email and webhook alerts, takes a cron expression with a timezone and a separate grace period, and can put the backup on a public status page. It doesn't schedule anything for you, and Healthchecks-style slug URLs and ?create=1 don't work: create the monitor first and use its own URL. For restic, runitor or a backup script of your own, see how to know if your backup actually ran; for other services that replaced Cronhub, see Cronhub alternatives.

Why the 2.1.7 case is the one to worry about

A config that fails to load can't ping anything, so the hooks that would have told you are switched off by the same error that stopped the backup. Only a check that alerts on silence notices that kind of failure, which is why a heartbeat with a deadline beats an alert on errors for backups; a dead man's switch for your scripts explains the idea.

Common questions

Last reviewed November 2026.

Related

• How to know if your backup actually ran — Backups fail quietly. How to verify a backup ran, why exit code zero is not proof, what to check about size and restore, and how to be told the night it does not happen.
• Cronhub alternatives — Alternatives to Cronhub for cron and heartbeat monitoring after its 2026 shutdown, compared on price, schedules, alerts and status pages.
• A dead man's switch for your scripts — What a dead man's switch is, why it catches failures that error-based alerting cannot, how to build one with cron and curl, and the timing rules that stop it crying wolf.