# Audit Logs: Who Did What, and When

> Monitor user activity and system events: summary tiles, filters by action, entity, role and status, and per-change field-level before/after detail.

Source: https://totalshiftleft.ai/help-center/product-documentation/audit-logs

## Overview

**Audit Logs** records who did what, and when. The page describes itself plainly: *"Monitor user activities and system events."*

Nav path: **Settings → System & Monitoring → Audit Logs**. Requires Administrator access.

This is the page you open when something changed and nobody knows who changed it — a project's base URL is suddenly wrong, a user has permissions they shouldn't, a schedule stopped. It's also the record you'll be asked for in a compliance review.

## Summary tiles

The tiles across the top give you the shape of activity before you start filtering:

| Tile | What it shows |
|------|----------------|
| **Total Actions** | How much happened in the current view. |
| **Top User** | Who was most active. |
| **Top Action Type** | The most common kind of action. |
| **Top Entity** | The most-touched thing. |

These are most useful as an anomaly check rather than a report. A **Top User** you don't recognize, or a spike in **Total Actions** overnight, is worth ten seconds of attention.

## Filters

**Filters** narrow the log:

| Filter | Purpose |
|--------|---------|
| **All Actions** | Filter by action type. |
| **All Entities** | Filter by the kind of thing acted on. |
| **All Roles** | Filter by the actor's role. |
| **All Status** | Filter by outcome. |
| **Username** | A specific user. |
| **Before** / **After** | Bound the time window. |
| **Search…** | Free-text across entries. |

The efficient way to use this page is to start from what you know and subtract. If a project setting changed, filter the entity and set **After** to the last time you know it was right. You're usually two filters away from the answer, not scrolling.

## Change details

Entries with changes are clickable — *"Click to view change details"* — and open a field-level view showing the **Field** and its **Kind** of change.

This is the part that makes the log worth having. Knowing that someone updated a project is mildly useful; seeing *which field* went from what to what is what actually resolves the question. When a run starts failing after a config change, this view tells you precisely what moved.

## Status

Entries carry a status, and failed actions are logged too — which is easy to miss and often the most interesting thing on the page. A run of failed authorization attempts against an entity is a different signal from a successful change, and it's the one worth noticing early.

## Retention

Audit retention is configurable on the **Enterprise** plan. Set it to match whatever your compliance regime actually requires rather than defaulting to as long as possible — a log you keep for years and never query is a liability, not an asset.

## What to check regularly

You don't need a daily ritual, but a periodic scan is cheap:

- **Permission and role changes** — the highest-consequence category. Someone gaining admin should be something you know about.
- **Project setting changes** — the usual explanation for "it worked yesterday".
- **Failed actions clustered on one entity or user** — either a misconfiguration or someone trying something they shouldn't.
- **Deletions** — deletes here aren't soft. The log is often the only record that something existed.

## Audit logs vs debug logs

These two get confused, and reaching for the wrong one wastes time:

| | Audit Logs | [Debug Logging](/help-center/product-documentation/debug-logging) |
|---|---|---|
| **Records** | User and system *actions* | Platform *internals* |
| **Answers** | "Who changed this?" | "Why is the platform misbehaving?" |
| **Audience** | Administrators, compliance | Support, engineering |
| **Retention** | Configurable on Enterprise | Rotation-based, often short |
| **Always on** | Yes | Level-dependent |

If a *test* failed, neither of these is your first stop — that's the [Detailed test report](/help-center/product-documentation/detailed-test-report). Audit logs tell you about changes to the system, not about your API's behaviour.

## A worked example

A pack that ran clean for weeks starts failing everywhere overnight. The reports show **Error** on every test, so nothing is reaching the API.

1. Open Audit Logs and set **After** to the last known-good run.
2. Filter entities to the project.
3. Look for setting changes — and there it is: a base URL edited yesterday afternoon.
4. Click through to the change details and see the exact before and after value.

That's a two-minute path to an answer that could otherwise burn a morning on connectivity theories. The reports told you *what* broke; the audit log tells you *who changed what*, which is the thing you actually needed.

## Troubleshooting

- **The log is empty for a period you know had activity** — check **Before**/**After** and the other filters before concluding anything is missing.
- **You can't find who changed a setting** — widen the time window. People's sense of "yesterday" is unreliable.
- **The page is unavailable** — you're not an Administrator.
- **An action you expected isn't there** — check whether you're filtering by role or status and excluding it.
- **Entries stop before a date you need** — you've hit the retention window. See [Administration settings](/help-center/product-documentation/administration-settings).

## Related articles

- [User management](/help-center/product-documentation/user-management)
- [Role permissions](/help-center/product-documentation/role-permissions)
- [User policies](/help-center/product-documentation/user-policies)
- [Administration settings](/help-center/product-documentation/administration-settings)
- [Debug logging](/help-center/product-documentation/debug-logging)