Skip to main content

Audit Log

The Audit Log is an append-only record of every administrative action taken in BEAK SWA. Each entry captures the actor, the action, the resource affected, the source IP, and a free-text detail string. Use the log to investigate configuration changes, satisfy compliance reviews, or trace the source of an unexpected state change.

Log Table​

The log is presented as a paginated table, oldest-to-newest within each page, with these columns:

ColumnDescription
TimestampWhen the action occurred, in your local time
UserThe actor — usually an admin email. System-driven actions show system in italics.
ActionThe action name as a coloured badge (see below)
ResourceThe type of resource the action targeted (e.g. user, role, category)
IP AddressThe source IP of the actor's request
DetailsA short free-text description of the change, truncated in the table — hover for the full text

Action Colours​

Action types are colour-coded to make scanning the log easier:

  • create — Green badge (new entity added)
  • update — Blue badge (existing entity modified)
  • delete — Red badge (entity removed)
  • login / logout — Grey badge (session events)
  • block — Red badge (entity disabled)
  • unblock — Green badge (entity re-enabled)
  • role_change — Purple badge (user role assignment changed)

Unknown action types fall back to a neutral grey badge.

Note: Action names are stored as dotted strings (e.g. user.create); the colour mapping uses the final segment after the last dot.

Pagination​

The log paginates server-side at 50 entries per page. Previous and Next buttons appear when more than one page is available, alongside a Page X of Y indicator. A search box in the table header lets you filter the loaded page by free text. The log is immutable — entries cannot be edited or deleted from the UI.

Best Practices​

  • Open the audit log first when investigating an unexpected configuration change — the actor, IP, and timestamp are usually enough to start a conversation.
  • Filter mentally by the User column: a single user driving many delete or role_change actions in a short window can be a sign of bulk cleanup, mistaken intent, or compromised credentials.
  • Pair entries with the affected resource — for example, a role_change entry should match a corresponding user state change visible on the Users page.
  • For compliance use cases, export the relevant time range periodically — the log is append-only but the UI is intended for live investigation, not long-term retention.
  • Users — User accounts and roles affected by audit entries
  • Roles — Role definitions referenced by role_change actions
  • General Settings — Configuration changes that show up in the log