The Audit Log is the full history of changes inside your organization. Every significant action (creation, modification, deletion, move, settings change, billing operation, permission change) is recorded as a separate entry with the author, time and context.
Why you need it:
- Investigation — "who deleted this article?", "who changed someone's role last week?"
- Compliance — SOC 2, ISO 27001, GDPR require an audit trail for data and consent changes
- Rolling back changes — understand what was there before a change and make a decision
- Team activity control — who is doing what, especially in Enterprise organizations with a large team
#Where to open
Left menu → Audit Log.
Available to the organization's Owner and Admin roles and only on the Business and Enterprise plans (plan flag allows_audit_logs). On Free, Starter and Pro the section is hidden.
Editor, User and Guest do not see the log.
#What an entry looks like
Each log row is a card with the author, action, resource, time and a short description:
Entry fields:
| Field | Description |
|---|---|
| Author | name + email of the user who performed the action |
Action (action) |
what happened: created, updated, deleted, restored, moved, published, etc. |
Resource type (resource_type) |
the object the action was performed on: article, collection, user, consent, billing, tenant |
| Resource title | the article name, collection name, user name — what you see in the regular UI |
Summary (summary) |
human-readable explanation of the action |
Details (details) |
JSON with additional data: what exactly changed, old/new value, IP address, idempotency key — expands on clicking "Details" |
| Time | timestamp with second precision |
#What goes into the log
The log records key operations on content, members, consents and billing. Below are the actual resource types and actions.
#Articles (resource_type=article)
| Action | When it fires |
|---|---|
created |
creating a new article |
updated |
saving changes (including a visibility change — details shows which fields changed) |
trashed |
moving an article to the trash |
restored |
restoring from the trash |
permanently_deleted |
deleting permanently from the trash or after retention expires |
#Collections and spaces (resource_type=collection)
Spaces are stored as top-level collections, so they are logged under the same resource type.
| Action | When |
|---|---|
created |
creating a collection or space |
moved |
moving a collection (changing its parent) |
collection_bulk_move_articles |
bulk-moving articles between collections |
trashed |
moving to the trash |
restored |
restoring from the trash |
permanently_deleted |
deleting permanently |
#Team (resource_type=user)
| Action | When |
|---|---|
role_changed |
changing a member's role in the organization |
deleted |
removing a member from the organization |
#GDPR consents (resource_type=consent)
| Action | When |
|---|---|
updated |
a user changed their cookie consent (scope: all / essential) |
These entries appear automatically when the cookie banner is changed. See the article on registration and onboarding for GDPR consent context.
#Billing and organization
| Action | Resource | When |
|---|---|---|
update_payment_method |
billing |
updating the payment method |
oned3_upgrade_rollback |
billing |
rolling back a failed upgrade with proration refund |
trash_emptied |
tenant |
fully emptying the organization's trash |
#Filters
At the top of the page there is a filter panel for quickly finding the event you need:
- Search — by text in
summaryorresource_title(case-insensitive) - Action — dropdown with all action types that appear in the organization's log
- Resource — dropdown with the types that actually appear in the log (
article/collection/user/consent/billing/tenant) - User — filter by the action's author
- Period — a "from" and "to" date range
- Pagination — up to 200 entries per page
Filters can be combined: for example, "all deleted actions by user Anna over the past week".
#Entry details
Clicking a card opens the expanded JSON in the "Details" field — this is the content of the details column in the database. What you can usually see there:
- For
updated— the list of changed fields (fields) - For
role_changed— the old and new role - For
consent updated— the scope (all/essential) - For billing operations — a short
summaryof what happened
Tip. If you need to understand what exactly changed in an article, look at the
fields_changedfield indetails. The full article content is not stored in the log (that would be expensive in terms of space) — for versioning use the article's Version History in the editor.
#Retention and compliance
- Log entries cannot be deleted through the UI — this is a deliberate limitation (otherwise the audit trail loses its meaning)
- Very old entries are periodically deleted by an automatic task under the audit retention policy — the log is not stored forever
- When the organization itself is deleted, the log is deleted along with it (via ON DELETE CASCADE)
#What does not go into the log
To avoid bloating the logs and turning the journal into noise, the following are not logged:
- Users' search queries — for analytics use the Analytics section
- Article views — also Analytics
- AI operations inside the editor (
AI Improve,AI Rewrite) — this is the author's workflow, not an auditable change - Technical events (background jobs, sync runs) — they are in the backend system logs, for platform admins
- Actions by system users (for example,
platform-help-systemwhen seeding documentation) — filtered out
#Related sections
- Trash —
trashed/restored/permanently_deletedevents for articles, collections and spaces are logged exactly here - Team management — role changes and member removals are recorded in the log with
resource_type=user - Analytics — for usage metrics (queries, views) — this is a separate tool, not the log