History
The portal records every operation it runs, so you always have an audit trail of what was done, by whom, and whether it succeeded. Staff users additionally get a log of sign-in activity.
There are two pages, both reached from the top navigation bar:
- Operation history — History
- Login history — Logins (staff only)
Timestamps. Dates and times are shown in your local timezone by default. Use the clock dropdown in the navigation bar to switch to UTC — the table headers update to show which timezone you’re viewing, and the choice is remembered by your browser. Hovering a timestamp shows the same moment in the other timezone.
The Ran column shows a job’s whole timeline as
date start → finish duration. A finish time on a later day is marked+1d.Jobs that ran before the portal recorded both ends of a run keep the same shape, with a dash in the slot they cannot fill — the dash sits before the arrow when only the finish time is known, and after it when only the start is. The oldest Host from Backup records were written once the copy had already completed, so their timestamp is a finish time; everything newer is a start time. Hover a dash for the reason. That history cannot be filled in retroactively, so those rows stay partial.
Operation history
Open History in the top navigation. The page is a single feed of every operation you can see, newest first, with the running jobs pinned above it.
In flight
Jobs still in progress appear first, in a highlighted In flight card. This panel spans every operation type and is unaffected by the result and time-range filters — a job that started last week is still running now, and a job of another type is still running while you read one type’s tab.
Where a job has a page you can watch, the row links to it: View progress for the portal’s own streaming jobs (host from backup, live transfers), or View output for the AWX-driven ones (migration, refresh, corruption check, object-storage re-host), where you can follow the live job output and cancel if needed.
Filtering
The filter bar above the feed narrows the list. All of the filters compose:
| Filter | What it does |
|---|---|
| Search box | Matches a file name or a server name, anywhere in the value. |
| Result | Running, Failed, Canceled, or OK. |
| Time range | Last 24 hours, 7, 30, or 90 days — by when the job started. |
| Server | Any operation touching that server, at either end of a transfer. |
| User | Who performed the operation. |
Failures this week is a shortcut for the most common question: it selects Failed plus the last 7 days in one click. Clear resets everything.
Filters survive switching tabs and paging, so you can narrow once and then look through the results by type.
Tabs
The tab strip splits the feed by operation type, and each tab shows how many rows it holds under the current filters — so a type with nothing to show reads as empty without your having to open it.
- All activity — every type, merged newest-first
- Host from Backup — on-server
- Object Storage — re-hosts from a duplicity backup
- Migrations
- Refreshes
- Transfers — live file transfers
- Copies — live file copies
- Downloads
- Corruption checks
- Compacts — file compacts
- Encryption — File Encryption changes; the row names the change that was made, never the passcode
On All activity, the servers and files involved are shown stacked, each under a small grey label naming the role it plays (“Clone host”, “Data file”). Opening a single type’s tab swaps in that type’s own columns, which carry the extra detail the merged view has no room for — the corruption-check table, for instance, also shows whether the recovered file was re-hosted.
Results
Every finished row carries a Result badge:
| Badge | Meaning |
|---|---|
| OK (green) | The operation completed successfully. |
| Failed (red) | The operation failed. Hover the badge to read the error. |
| Canceled (yellow) | The job was canceled before it finished. |
Failure messages are raw operational detail — an API response, an SSH error — so they live in the badge’s tooltip rather than in the row. For the AWX-driven operations, View output is usually the better place to look: it has the full job log rather than just the final error.
Whose history you see
- Regular users see every operation that ran against a server they can access, whoever performed it — including their teammates’.
- Staff users see everything.
The server and user dropdowns only ever offer what you’re allowed to see, and filtering cannot widen that.
Long lists are paginated, 50 rows per page.
Login history (staff only)
Staff users see an extra Logins item in the navigation that opens the sign-in audit log. (Non-staff users cannot reach this page.)
Each row records one authentication event:
| Column | Description |
|---|---|
| Timestamp | When the event occurred, in your selected timezone (local by default). |
| Event | Login (green), Logout (grey), or Failed (red) sign-in attempt. |
| The account the event relates to. | |
| IP address | Source IP of the request, if known. |
| User agent | The browser/client string, if known. |
Two dropdown filters at the top let you narrow by user and by event type (Login / Logout / Failed); a Clear link resets them. The log is paginated (50 rows per page).
This page is useful for confirming who has been accessing the portal and for spotting repeated failed sign-in attempts.