Audit Logs: Who Did What, and When

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:

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:

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:

If a test failed, neither of these is your first stop — that's the 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.

Related articles

• User management
• Role permissions
• User policies
• Administration settings
• Debug logging