---
title: Audit Log
description: Track all mutating actions across your Sencho instance with a searchable, exportable audit trail for team accountability.
---

<Note>
  The Audit Log requires a Sencho **Admiral** license. Skipper and Community Edition do not include this feature.
</Note>

<Note>
  Audit is hub-only and is hidden from the nav strip when a remote node is the active selection. See [Multi-Node Management](/features/multi-node#what-top-level-views-show-when-a-remote-node-is-active).
</Note>

Sencho Admiral records every mutating action (deploy, stop, delete, settings changes, user management) with full attribution. The audit log answers the question every team eventually asks: **"Who changed what, and when?"**

## What gets logged

Every `POST`, `PUT`, `DELETE`, and `PATCH` request to the Sencho API is automatically recorded with:

| Field | Description |
|-------|-------------|
| **Timestamp** | When the action occurred |
| **User** | The authenticated username that performed the action |
| **Method** | HTTP method (`POST`, `PUT`, `DELETE`, `PATCH`), shown as a color-coded badge |
| **Action** | Human-readable summary (e.g., "Deployed stack: nginx-proxy") |
| **Status** | HTTP response status code, color-coded by result (green for success, yellow for client errors, red for server errors) |
| **Node** | Which node the action targeted, or `-` for local-only actions |

Expanding a row reveals additional detail:

| Field | Description |
|-------|-------------|
| **Request Path** | Full API path of the request |
| **IP Address** | Client IP address |
| **Node ID** | Numeric node ID, or "Local" for local actions |
| **Entry ID** | Unique identifier for the audit entry |

### Example actions tracked

- Stack lifecycle: deploy, stop, start, restart, update, rollback, delete
- Stack creation, file edits, and env file changes
- Container operations: start, stop, restart
- Node management: add, update, delete
- User management: create, delete, role assignment and removal
- Password changes and node token generation
- Settings changes
- System prune operations (general, orphans, system)
- Image, volume, and network deletion
- Network creation
- License activation/deactivation
- Webhook and notification agent configuration
- Notification route management and testing
- Fleet backup creation, restoration, and deletion
- Fleet node updates (individual and fleet-wide)
- Scheduled task management
- Registry credential management
- SSO configuration changes and connection tests
- API token creation and revocation
- Label management and bulk actions
- Template deployments
- Auto-update execution
- Console token generation

## Viewing the audit log

Navigate to the **Audit** tab in the sidebar. This tab is visible to users with the **Admin** or **Auditor** role on an Admiral license.

The Audit Log has two views, toggled from the header: **Stream** (default) and **Table**.

### Stream view

Stream gives you an at-a-glance read on activity. A signal rail at the top summarizes the last 24 hours across four tiles, and the feed below groups entries by day with severity dots, relative times, and inline anomaly callouts.

<Frame>
  <img src="/images/audit-log/audit-stream.png" alt="Audit Log Stream view showing the signal rail with events, actors, failure rate, and peak hour tiles above a day-banded chronological feed" />
</Frame>

**Signal rail tiles:**

| Tile | What it shows |
|------|---------------|
| **Events · 24h** | Count of audit entries in the last 24 hours, with a percent change versus the prior 7-day average |
| **Actors** | Unique users active in the last 24 hours; notes the count of new IP addresses when present |
| **Failure rate** | Share of 24-hour requests with 4xx or 5xx responses, rendered with an inline sparkline of the hourly failure trend |
| **Peak hour** | The hour with the highest activity, flagged in amber when it falls outside 08:00-18:00 |

**Feed entries:** each row shows the relative time (e.g. `58m ago`), a severity dot (green for 2xx, amber for 3xx, rose for 4xx/5xx), the actor and action summary, a meta line with exact timestamp, node, status code, IP, and any anomaly flags, and the method and path on the right.

Rows colored in rose or amber indicate failures; the tinting makes spikes of errors visible at a glance.

### Table view

Table keeps the full-featured detail grid for power users: exact timestamps, method badges, action summaries, and status codes in sortable columns. Clicking any row expands it to show the full request path, IP address, node ID, and entry ID.

<Frame>
  <img src="/images/audit-log/audit-log-overview.png" alt="Audit Log Table view showing the action table with search filters, color-coded method badges, and export controls" />
</Frame>

<Frame>
  <img src="/images/audit-log/audit-log-expanded.png" alt="Audit Log Table view with an expanded row showing request path, IP address, node ID, and entry ID" />
</Frame>

The header displays the total number of matching entries and provides **Refresh** and **Export** controls in both views.

Results are paginated at 50 entries per page. Navigation controls appear at the bottom of the feed or table when there are multiple pages.

## Anomaly detection

In Stream view, Sencho annotates individual entries with lightweight anomaly flags that help you spot activity that deviates from an actor's normal pattern. Flags appear inline in the entry's meta line, after the IP address.

| Flag | When it fires |
|------|---------------|
| **unusual hour** | The entry's hour sits outside the actor's typical activity window, computed from the central 90% of their last 7 days. Requires a baseline of at least 5 prior entries to avoid flagging new users. |
| **new ip** | The IP address on this entry has not been seen for this actor in the last 30 days, and the actor already has prior history. |
| **first seen** | The actor has no prior entries in the 30-day history window. Useful for spotting brand-new service accounts, CLI tools, or compromised sessions. |

Flags are computed at read time against your existing audit history. No new tables, no per-entry storage overhead, and the logic is cache-friendly, so enabling Stream view does not slow down the audit log endpoint.

## Filtering and search

The audit log provides several ways to find specific entries:

- **Full-text search** - Search across action summaries, API paths, and usernames
- **Method filter** - Filter by HTTP method (POST, PUT, DELETE, PATCH) using the dropdown
- **Date range** - Set a start and/or end date to narrow results to a specific time window

All filters work together and are applied server-side with pagination.

## Export

Export the currently filtered audit log dataset as **CSV** or **JSON** using the **Export** dropdown in the header. The export respects all active filters, so you can narrow down to a date range or specific user before exporting.

Exports are capped at 10,000 entries per download.

## Auditor role

The **Auditor** role provides read-only access to the audit log without granting any administrative privileges. Auditors can:

- View the full audit log
- Search and filter entries
- Export audit data as CSV or JSON
- View stacks and nodes (read-only)

Auditors **cannot** modify settings, manage users, deploy stacks, or perform any other administrative actions. This role is ideal for compliance officers, security reviewers, or team leads who need visibility into system activity without operational access.

To create an Auditor user, go to **Settings > Users** and select the **Auditor** role when creating a new user.

## Configurable data retention

Audit log entries are automatically cleaned up based on your configured retention period. The default is **90 days**.

To change the retention period:

1. Go to **Settings > Developer > Data Retention**
2. Set the **Audit Log Retention** value (1-365 days)
3. Click **Save Developer Settings**

<Frame>
  <img src="/images/audit-log/data-retention.png" alt="Data Retention settings showing Audit Log Retention set to 90 days" />
</Frame>

Cleanup runs automatically as part of Sencho's periodic maintenance cycle.

## Security at rest

Sensitive database values (such as remote node API tokens) are encrypted at rest. The encryption key is stored separately from the database, ensuring that database file exposure alone does not compromise secrets.
