Audit log

Every workspace keeps a trail of the actions that change who can do what. It is written once and never edited, and it is pruned after 90 days.

What is recorded

• Roles - created, updated, deleted. An update carries a diff: which permissions were added, which removed, and whether the name, description, colour or default flag changed.
• People - invited, removed, role changed, status changed, ownership transferred, and page-scoped grants added or revoked.
• Tokens - created and revoked, including the asset tokens that sign private media.
• The workspace - settings updated, and the draft secret regenerated.
• Editorial stage changes on a page.

Each entry names the actor, the entity, and when it happened.

What is not, and why

Content edits are not in the audit log. No page saves, no block tweaks, no media uploads.

That is a deliberate line, not an oversight. Those events are high-volume - a busy afternoon produces hundreds - and mixing them in would bury the fifteen entries that matter under thousands that do not. The audit log answers "who changed access"; for "who changed this page", the page's own version history records every save with its author.

The rule of thumb behind the list: it covers what affects trust, authentication and billing, and what an attacker would want to cover their tracks about.

Who can read it

Reading the log requires the permission to manage roles. That is intentional - the log is largely a record of permission changes, so the people who can grant access are the people who can see who granted it.

Ninety days

Entries older than ninety days are pruned by a scheduled job. If your retention obligations are longer than that, export what you need on a schedule rather than discovering the gap during an audit.

Next steps

• Members and roles - the permissions whose changes land here.
• API tokens - creation and revocation, both recorded.
• Version history - the content trail this one deliberately leaves out.