Audit log
Every sensitive Backup operation — who did it, when, and to what — including the system workers, with filters for investigation.
The audit log (Backup → Audit log, under Operations) is a read-only timeline of every action against your Backup resources: datasources created, credentials set, policies attached, jobs queued / started / completed / failed, destinations edited, download links minted, and the system workers' own interventions.
Use it to answer:
- "Who deleted that datasource last Tuesday?"
- "When were the production credentials last rotated?"
- "Did the nightly run actually start, or is something wedged?"
- "Has anyone generated download links for our backups?"
What an entry records
| Field | Content |
|---|---|
| When | Timestamp; the list is newest-first. |
| Actor | The user (name/email), with a System badge for background workers (scheduler, reaper, retention) and an API badge for machine actors. |
| Action | What happened, e.g. datasource.created. |
| Target | The resource type and ID. |
| Details | Action-specific metadata — e.g. which policy a manual run used, or why the reaper reclassified a job. Deliberately redacted: never credentials, never download URLs. |
Entries also capture the request's IP address and user agent.
What gets recorded
| Category | Actions |
|---|---|
| Datasource | created, updated, credentials set, activated, deactivated, deleted, verify attempted |
| Backup policy | created, updated, deleted, attached to datasource, detached from datasource |
| Backup job | queued, started, completed, failed, manual run, deleted, download link generated |
| Backup job (reaper) | reaped — stuck task, reaped — healed to success, reaped — orphan cleaned |
| Destination | created, updated, re-verified, deleted |
| Restore | created, started, completed, failed, reaped — stuck, log link generated |
Reads are never audited — browsing job history or viewing a datasource leaves no trace. The one "read" that is: download link generation, because a minted link is access to your data.
System actors are first-class
Much of what happens in Backup is done by the system on your behalf, and it's all attributed: the scheduler queues jobs, the reaper heals or fails stuck ones, workers complete them. Filter Actor to System to see the machinery; filter it out to see only human actions.
Filtering
Combine independently — as the page says, "each narrows the server query independently":
- Date range presets — All time, 24h, 7d, 30d.
- Action — multi-select, grouped by category.
- Target — by resource type.
- Actor — multi-select across the users (and System) that appear in your log.
Last 7 days + destination actions answers "did anyone touch our storage credentials this week?" in two clicks. The list loads more as you scroll.
Retention and GDPR
- Audit entries are kept for one year, then pruned automatically.
- Retention deletions have their own permanent trail — the record of which backups the retention worker deleted, when, why, and how many bytes were freed is kept forever, separate from the 1-year general log.
- Right to erasure is honoured without breaking the trail — actor identities are resolved live, so users who deleted their account appear as "Anonymized user" per GDPR (as the page header notes). See Platform → GDPR.
Access over the API
The same data is available at GET /audit-log with cursor pagination
and filters for time range, actions, target types, a specific target
ID, and actors; GET /audit-log/actors lists the distinct actors for
building pickers. Backup emits no webhooks — polling the audit log with
an action filter is the supported way to feed events into a SIEM. See
the API reference.
Related
- Backup jobs — the lifecycle whose every step lands here.
- Encryption and security — what's redacted and why.