Servatum documentation

Servatum has two parts. Proof collects the result of every backup job you already run, checks it against the schedule you expect, and reports the status to your monitoring, your team and, if you choose, your customers. Vault is offsite storage your servers can write to but never delete from.

You can use either on its own. Used together, backups stored in the vault report to Proof automatically.

Core concepts

Quickstart

1. Create an account and name your first job, for example nightly-full.
2. Set the schedule: when the job should finish and how much grace to allow.
3. Connect the source: a hook, the CLI wrapper, a webhook or email. See Ingest below.
4. Add destinations: email, Slack or Telegram for alerts, and PRTG, Zabbix or Prometheus if you run them.
5. Optionally publish a proof page on your own domain.

From then on, every run is checked automatically. A job that fails or stops reporting raises an alert within its grace period.

Run API (webhook)

Report a finished run with one HTTPS request. The job key identifies the job; no other authentication is needed for reporting.

POST https://in.servatum.io/v1/jobs/{job_key}/runs
Content-Type: application/json

{
  "status": "ok",
  "started_at": "2026-10-24T00:00:04Z",
  "finished_at": "2026-10-24T00:37:12Z",
  "size_bytes": 48211993600,
  "snapshot_id": "a1b2c3d4",
  "message": "1,204 accounts, 0 errors"
}

status is ok, failed or running. Every other field is optional. Size and duration trends are tracked, so a backup that suddenly shrinks is flagged even when it reports ok.

Heartbeat URLs

For tools that can only call a URL. Call it on success; if the call doesn't arrive within the schedule and grace period, the job turns missing.

curl -fsS https://in.servatum.io/p/{job_key}          # success
curl -fsS https://in.servatum.io/p/{job_key}/start    # job started
curl -fsS https://in.servatum.io/p/{job_key}/fail     # job failed

CLI wrapper

The open-source servatum agent wraps any command. It reports start, finish, exit code and duration, and reads extra detail (snapshot ID, bytes added) from restic, borg and rclone output.

export SERVATUM_JOB_KEY=nightly-full:xxxxxxxx
servatum run -- restic backup /home --tag nightly
servatum run --job db-dump -- pg_dump -Fc app > /backup/app.dump

The wrapper never changes your command's exit code, so existing cron alerts keep working.

JetBackup and cPanel

JetBackup 5: install the Servatum hook script, then add it in JetBackup as a Post Backup hook (and optionally a Post Backup Account hook for per-account results). Each job reports status, size, duration and destination.

cPanel native backups: the same script runs as the WHM post-backup hook and reports which accounts were backed up and which were skipped.

Hosts get one proof page per client account if they want it, white-labelled under their own brand.

Email ingest

Every account gets an inbox address. Point the notification emails of tools like Veeam, Veritas Backup Exec, Acronis, Proxmox or Synology at it. Servatum recognises the sender, reads the job name, result, size and warnings, and matches the email to the right job.

{account}@in.servatum.io

Outgoing webhooks

Every run and every status change can be sent as JSON to your own URL. Requests are signed with HMAC-SHA256 in the X-Servatum-Signature header so you can verify they came from Servatum.

{
  "event": "job.status_changed",
  "job": "nightly-full",
  "tier": "offsite-a",
  "from": "ok",
  "to": "missing",
  "last_success_at": "2026-10-23T00:37:12Z",
  "incident_id": "inc_01J..."
}

PRTG, Zabbix, Prometheus

PRTG: Servatum pushes one channel per tier (status, hours since last success, size) to an HTTP push sensor, or PRTG polls the account's JSON endpoint.

Zabbix: values are sent to trapper items, one per tier, or read by an HTTP agent item. Triggers stay in Zabbix.

Prometheus and Grafana: each account exposes a metrics endpoint you can scrape.

servatum_tier_status{job="nightly-full",tier="local"} 1
servatum_tier_last_success_timestamp_seconds{job="nightly-full",tier="local"} 1792800000
servatum_tier_size_bytes{job="nightly-full",tier="local"} 48211993600
servatum_tier_retention_points{job="nightly-full",tier="offsite-a"} 34

Uptime Kuma and Healthchecks.io: Servatum calls your push or ping URL after each good run, so silence shows up in the tool you already watch.

Proof page and JSON

A proof page shows each tier's status, last known good backup, retention depth, restore-test age and a 90-day incident history. Point a CNAME such as proof.yourdomain.com at Servatum to host it on your own domain.

The same data is available as /proof.json and as an embeddable badge.

How the vault works

The credentials your servers use can add new backups but cannot delete or overwrite existing ones. Pruning old backups happens only on the vault side, according to the retention policy you set in the dashboard. If an attacker takes over your server, they cannot destroy your history in the vault.

• Encryption happens on your side before upload. We never hold your key, so if you lose it, nobody can recover the data. Keep it somewhere safe.
• Regions: a single region, or dual for a second independent copy.
• Retention changes that shorten history take effect after a delay, so a compromised dashboard login cannot wipe backups instantly.
• Billing is per TB stored, measured daily.

Using the vault with restic

export RESTIC_REPOSITORY=rest:https://{user}:{token}@vault.servatum.io/{repo}
export RESTIC_PASSWORD_FILE=/root/.restic-pass

restic init                      # once
restic backup /home /etc /var/lib/mysql-dumps
restic snapshots                 # list restore points
restic restore latest --target /restore

restic forget and prune are refused from your side by design. Every backup into the vault appears in Proof automatically, with no extra setup.

Security and privacy

• Proof only receives metadata about runs, never backup contents.
• Vault data is encrypted before it leaves your server.
• Job keys can only report runs; they cannot read data or change settings.
• Dashboard logins support two-factor authentication.
• A data processing agreement is available for customers in the EU.

What ships at launch

Something you need isn't listed? Tell us when you join the waitlist; early requests shape what ships first.