Activity Log
What everyone with access has changed on this server — one table, 200-odd event types, filtered by family and searched by value.
Activity Log is the server's audit trail. Every change the panel makes to this machine is written to it: applications created, backups restored, firewall rules added, PHP versions installed, settings saved.
It is the counterpart to Account → Activity, and the split is one question: is this row about the machine, or about the panel's people? Logins, password changes and role assignments are people, and they are deliberately not here.
Where it is
Activity Log in the sidebar, between Backups and Server Sync.
Reading a row
| Column | What it holds |
|---|---|
| When | Relative — "24 minutes ago". |
| User | The @username that did it, or System when nobody did. |
| Type | The feature family, colour-coded so a long page can be scanned. |
| What happened | A full sentence, in your language. |
System is a real answer, not a missing one. A scheduled backup, an automatic disk clean, a deploy triggered by a Git webhook — nobody was there, and the panel says so rather than attributing the action to whichever administrator happened to be nearest.
The type badges are grouped by colour: people, security, runtimes, sites and housekeeping each get their own, so you can pick out "everything that touched the firewall" without reading a word.
Filtering
Filter by type. The dropdown lists every server-side family the panel can record — 22 of them on a current install.
There is no User, Role or Permissions entry here. Those are account families, and they are on the Account page by design.
The full list is what an administrator sees. Without admin access the dropdown is built from the families you have rows in rather than from the catalog, so it can be much shorter — or absent altogether on an account that has not changed anything yet. The table itself still shows every server event you are allowed to see; only the filter list is narrowed.
Pick one and the table narrows immediately. The choice is kept in the URL as
?type=backup, so a filtered view is a link.
Or search. The box matches the event's type, its internal action name, and
the values recorded with it — so my-blog finds every event about that
application, and 198.51.100.9 finds the ban. It does not match the
translated sentence in the last column.
There is no filter on the event itself and no date range. The panel filters on exact, untranslated event ids, which would make a dropdown of them unreadable in any language — so it offers the family instead.
Paging through it
Ten rows a page, with 20, 50 and 100 available, and a total count beside the page numbers.
A bookmarked ?page= that is out of range redirects to a page that exists,
rather than rendering an empty table that reads like "nothing ever happened".
Permissions
The screen is gated on Activity Log · View. Without it the sidebar entry is absent and the URL answers with the standard "you don't have access" page.
Three separate logs exist, and the permissions are not interchangeable:
| Log | Shows | Needs |
|---|---|---|
| Account → Activity | Your own account events | Nothing — any signed-in user |
| Activity Log (this screen) | Every server event, by every user | activity_log · View |
| Admin activity log | Everything, including account events for every user | Admin access |
Granting Activity Log · View lets someone read what everyone has changed on the server, including actions in features they cannot otherwise see. It is a read-only permission, but it is a wide one.
Known issue: the hover timestamp is wrong
Hovering the When column is supposed to show the exact date and time. It does not, reliably:
The API sends timestamps as DD-MM-YYYY HH:MM:SS and the browser reads them as
MM-DD-YYYY. The result:
- On days 1–12 of a month, the tooltip shows a plausible but wrong date — 5 October reads as 10 May.
- On days 13–31, the date cannot be parsed at all, so no tooltip appears.
The relative time in the column is correct — it is calculated server-side and not affected. Only the hover is. Verified on OSS Panel 1.0.14; treat the tooltip as unreliable until it is fixed upstream.
Caveats
- Rows cannot be deleted or exported from this screen, and there is no retention setting — the log grows with the panel's database.
- Per-application history is elsewhere. Deployments, that application's backups and its own logs are on the application's own screens; this log carries the server-level summary.
- A few event types are retired — recorded by versions of the panel that no longer exist. Their sentences are kept so old rows still read properly, but they are left out of the filter dropdown, where they could only ever match nothing.
- The log records what the panel did. A change made by hand over SSH does not appear here; Server Sync is how the panel catches up with those.
Restore an application
Put a backup back over a live application — what the panel does first, how to watch it, and how to undo it.
Integrations
Credentials that live somewhere else — a Git account, a storage destination, a container registry login — stored once and reused by the features that need them.