Activity log

The Activity log is the audit trail for one server. Every ban, kick, unban, config save, admin change and automated fix lands here with a timestamp and the name of whoever caused it. It is the page to open when you need to know who did something and when.

Reading the table

Six columns: Time, Type, Player, Details, Member and Actions. Twenty rows per page. The Player cell is a link into Lookup for that player, and Details carries whatever the row has, usually a reason and a ban id, or a one-line summary of what an automated fix changed.

Clicking a row opens the full record. From there a ban row offers Unban and, when the ban carries detection context, the Raven Mind route. An unban row offers Restore ban. Both are gated on the same permissions the buttons need elsewhere, so the modal never offers something you would be refused.

Filtering

• Search box. Filters the rows currently on screen by player name, reason, Steam id or the member who performed the action. It narrows the page you are looking at rather than searching the whole history, so combine it with a type or date filter when you are hunting through a long log.
• Activity. One event type at a time, grouped into Players, Admin team, Server admin and Raven Mind. This one is applied by the server, so it searches the whole history.
• Player. Every player name that appears anywhere in this server log, not only on the current page.
• From and To. A date window, also applied server side.

The event types

Players

• BAN_PLAYER and KICK_PLAYER. An admin banned or kicked from the Players List, the map, or the Bans List. The Member column names them.
• BAN_API and KICK_API. The resource acted on its own, which means a detection fired. These two are what the Detections line on the overview charts counts, and everything else counts as an action.
• UNBAN_PLAYER. A ban was lifted, from the Bans List, from this log, or by the resource calling the unban endpoint.

Admin team

• ADD_ADMIN, REMOVE_ADMIN and UPDATE_ADMIN. Written by the Admins page. The add and update rows carry the resulting permission set, so a permission change is reconstructable later; a removal row carries the name only.

Server admin

• CONFIG_UPDATE. A Main Settings save that actually changed something outside the detections.
• PROTECTION_RULES. A save that changed the detections. One save can write both rows, and a save that changed nothing writes neither.
• SCREENSHOT and RECORD. A capture was taken and stored. Details carries a link that opens it in place, or a note that it was removed to save storage. A capture the game handed back empty is never stored at all: the row links the black screen card instead, and opening it says the frame came back empty, so an empty capture is never read as one that was reaped.
• IP_RESET_REQUEST. The owner asked for the license to be unbound from its address. See IP reset requests.
• PROXY_UPDATE. A historical type from when servers were reached over an inbound address. Nothing writes it now.

Raven Mind

The automated false-positive system writes its own rows: a rule proposed, applied, reverted, escalated or promoted, a live auto-unban, a resolution, a re-ban, a whole wave resolved at once, and a resource consolidation. Every one of these attributes to Raven Mind in the Member column rather than to the admin who happened to click, because the row records the decision maker. The underlying user is still stored for tracing.

Review a potential false ban covers what these rules do to your config.

Access

Reading the activity log needs the dashboard permission, which is the same permission that opens the server at all. In practice anyone who can open the server can read the log. Individual row actions need their own permissions, so a viewer without ban rights sees the ban rows but gets no Unban button.