Audit log — who did what, when

The audit log is the answer to "who did what, when?" — every admin-side action that mutates state is recorded with the actor, the target, the timestamp, and a JSON metadata blob. Use it to investigate a misconfiguration after the fact, to satisfy a regulator who needs proof of access controls, or to track what an automation did overnight.

What's recorded

A non-exhaustive list of action categories that land in the log:

Tool — created, edited, deleted, secret rotated, tested.
Document — uploaded, deleted, reprocessed.
Conversation — notes updated, snippet created from a turn, handoff resolved.
Snippet / knowledge — created, edited, deleted; merge-proposal decisions.
Team — invites sent, revoked, members removed, permissions changed.
Settings — SSO config saved, widget config changes, billing actions, data-export requests.
Compliance — DPA requested, sent, canceled; subprocessor list acknowledged.

Read-only browsing (looking at the leads list, opening a settings page) is not logged, and neither are sign-ins — the log covers state-changing admin actions only.

Filtering the log

The filter bar lets you narrow by:

Action — pick from the Action dropdown (tool.create, document.upload, etc.). The list is fixed; you can't search for ad-hoc patterns.
Date range — From / To date fields for a custom range.
Free-text — searches the actor email, the entity id, and the action name. It does not search the JSON metadata.

The page shows 50 entries at a time; pagination at the bottom.

What's in each row

When — exact timestamp, in your local time.
Actor — the email of the person (or service) who did the action. SSO-provisioned members appear with their IdP-asserted email. System actions (cron jobs, automated cleanups) appear as system.
Action — noun.verb style; tool.create, team.remove_member, tenant_dpa.send.
Entity — what was acted on. Usually a name or id; click into the row for the raw JSON.
Metadata — additional context (before/after values, which field changed). Some historical entries have empty metadata; we've been gradually filling it in.

Export to CSV

The Export CSV button dumps the currently-filtered view to a CSV. Useful for:

Sharing with your auditor or security team.
Importing into a spreadsheet for ad-hoc analysis.
Long-term retention beyond what we keep on the page.

The button is always shown, but the export itself has to be enabled on your workspace. If clicking it gives you a "not enabled for this workspace" error, email us to enable.

Retention

Log retention is a fixed 365 days for every workspace. The page surfaces a retention note — anything older than that window has been purged. If you need longer retention, export periodically.

Common questions

Who can see the audit log? Currently any member can read it. Sensitive metadata (passwords, secrets) is never logged in the first place.
Where do I see who signed in? You don't — sign-ins (password or SSO) aren't audited. The log records state-changing admin actions only.
Can I export beyond the displayed window? Only what's in the current filter. Filter by your desired date range first, then export.
Why doesn't action X appear? Either it's a read-only browse (not logged by design) or it's a recent feature where metadata is still being filled in. If you think a write was missed, file a bug.
How long is the log kept? 365 days, for every workspace; the retention note on the page says the same.
What's a system actor? A scheduled job or an automated cleanup did the action — no human pressed a button. E.g. retention purge, webhook retry.

See also team for permissions and compliance for DPA actions in the log.

Where to find us

Stuck? Email wilow@werila.com. If you need the audit-log CSV export turned on, mention that.