The Backup Runs page is the receiving end of the hostatlas-backup CLI. Every invocation of the CLI on any linked host pushes a summary here, so you can see at a glance which backups ran, which failed, and how big they were — across your whole fleet.

Open it from the sidebar under Monitoring → Backup Runs, or at /backup-runs.

What you see

Header KPIs:

• Total runs on the current filter.
• OK — runs that finished cleanly.
• Failed — runs where any source or the pipeline errored.

For each run:

• Hostname — the machine that produced the run.
• Profile — which entry in backup.yml was run (e.g. nightly, weekly-full).
• Started at — timestamp.
• Duration — total wall time.
• Total size — sum of all archives written.
• Destinations — S3, SFTP, local, or a mix.
• Sources — per-source pass/fail badges.
• Status — OK or failed.

Filters: search on hostname or profile, filter by status, filter by host.

Click a row to see the run detail.

Run detail

The detail page shows everything the CLI reported:

• Full timing breakdown (per source, per pipeline stage).
• Per-source result: bytes read, bytes written, retention applied, verification result.
• Per-destination result: upload duration and bytes shipped.
• Heartbeat status (if the run pings a heartbeat slug).
• The raw run summary JSON the CLI pushed.

Failed runs highlight the source(s) that caused the failure so you don’t have to scroll for it.

What you can do

The page is read-only — the source of truth is your host’s backup.yml, and the CLI is what produces these rows. You can:

• Filter to a specific host or profile to see a run history.
• Follow the heartbeat link to the associated heartbeat — useful when you also want a miss alert.

How it works

The hostatlas-backup CLI runs on a schedule you configure (cron, systemd timer, or manual). At the end of every run it POSTs a summary to HostAtlas, carrying:

• Host identity (via the CLI’s API token).
• Which sources ran, and whether each one succeeded.
• Which destinations received the archive, and how many bytes.
• Whether verification passed (a failed verify counts the whole source as errored).
• Timing for every stage.

The row appears here within seconds of the CLI finishing. If the CLI is also configured with a heartbeat slug, ?start / ?ok / ?fail pings flow into the associated heartbeat in parallel — so “backup never ran” and “backup ran but failed” are two distinct alerts.

Note

This page shows what the CLI told us. It does not check that files landed correctly at the destination — the CLI does that check itself (verification), and the result is reported here. If you want continuous outside-in monitoring of the destination folder, add a Backup Monitor pointed at the destination path.

Related

• hostatlas-backup CLI — install and configure the CLI that pushes these rows.
• Backups — passive file-level monitoring on any backup folder.
• Offsite Backups — encrypted upload to HostAtlas storage.
• Heartbeats — get alerted when a scheduled run does not report in.