Project Audit Logs Enterprise Grid
The project audit log is a focused record of security-relevant activity within a single project. It gives project admins an accountable, time-stamped history of who changed the project's configuration, membership, permissions, and settings.
Like Workspace Audit Logs, project audit entries are append-only and tamper-evident: they are written once and can never be edited or deleted, by anyone, including administrators. In fact, project and workspace audit entries are the same underlying records. The project audit log is the slice scoped to one project, so a project admin can review their own project's history without needing access to the whole workspace.
Where to find it
Go to Project settings → Audit logs. The page shows the most recent events first, with filters and an export option at the top. Its description reads "Track and review security-relevant activity within this project."
What gets tracked
The log covers the project's own lifecycle and settings, who's in it and what they can do, the structure its work runs on, and the destructive actions that an auditor would want to see. It doesn't record ordinary edits to individual work items; those are in each work item's activity.
In short:
- Project events are configuration changes: settings, feature switches, and the create, update and delete of states, labels, estimates, views, workflows, automations, cycles, modules, recurring work items, templates and releases, plus intake and page administration.
- Member events record who joined, left or was removed.
- Permission events record role changes.
- Security events record access to the log itself, plus deletions and bulk operations on work items, comments and attachments.
| Category | Events tracked |
|---|---|
| Project | Project created, settings updated, deleted; feature turned on or off; states created, updated, deleted, reordered or default changed; labels updated, grouped or ungrouped; estimates and estimate points created, updated or deleted; views created, updated, deleted or visibility changed; workflows created, updated, deleted, and their transition rules, hooks and approvers added, removed or updated; automations created, updated or deleted; cycles and modules created, updated or deleted; recurring work items created, updated, paused, resumed or deleted; work item types imported and overrides created or removed; intake forms published, unpublished, created, updated or deleted, intake email turned on or off, intake settings updated, intake items accepted, declined or marked duplicate, submissions received; pages archived, unarchived, deleted, restored, moved, access changed, public link created or revoked; project-scoped templates and releases created, updated or deleted; worklogs edited, deleted, exported or downloaded by someone other than their author |
| Member | Member added to the project, member removed from the project, member left the project |
| Permission | Project member role changed |
| Security | Audit log searched, exported, and export downloaded; work items deleted, bulk deleted, bulk updated or bulk archived; comments deleted, deleted by someone other than the author, or bulk deleted; attachments deleted. A bulk operation is one entry with the count of items it touched. |
Reading and exporting the project audit log are themselves recorded as events, so every access to the log is accountable.
The project audit log deliberately covers only project-scoped activity. Workspace-wide events, such as sign-ins, plan changes, API tokens, and webhooks, are not shown here. Those belong to the workspace audit log and the instance-level logs.
Read the log
Each row represents one event, with these columns:
| Column | What it shows |
|---|---|
| Timestamp | The date and time the event occurred, in your local time |
| Actor | Who performed the action, shown by name or email. System-generated actions show as Plane |
| Event | The action that took place, for example "Project member role changed" |
| Event object | The target the action was performed on, for example the affected member or the label that changed |
| Category | The category the event belongs to, with an icon |
Behind each entry, the log also captures additional context that appears in exports, including the actor type (user, API token, system, or anonymous), the outcome (success or failure), the reason for a failure, the IP address, the user agent, the source (Platform, API, Mobile, Authentication, God Mode or System) and, where relevant, the old and new values that changed.
Actor identity is stored as a snapshot at the time of the event. If a member is later renamed or removed, historical entries still show who they were when the action happened.
Filter and search
Use the filters at the top of the page to narrow the log:
- Category: Project, Member, Permission, or Security
- Outcome: Success or Failure
- Actor: events performed by a specific person
- Date range: events Before a date, After a date, or within a Range
- Search: free-text search across events, in the Search events box
Filters combine, and the filters you apply also determine what is included when you export. Click Clear all to reset them. The page is paginated, with a per-page selector and a "Showing {start}-{end} of {total}" count. When nothing matches, it reads "No audit logs yet" with a Clear filters button.
Export the log
You can export the project audit log for offline review, archiving, or handing to auditors.
- Apply any filters you want the export to respect.
- Click the Download button.
- Choose a format: CSV, JSON, or Excel.
Plane shows "Export started" and "Your audit log export is being prepared. It will appear below once it is ready." The export runs in the background. When it is ready, download it from the Previous exports list, which records who exported, when, the format, and the status. Because exporting reflects your current filters, you can produce a targeted export, for example only this month's membership changes, rather than the entire log.
Data integrity
The project audit log is designed so it can be trusted as evidence:
- Append-only. Entries cannot be modified or deleted after they are written. This is enforced in the application and at the database level, so there is no path, even for an administrator, to alter history.
- Tamper-evident. Each entry is cryptographically chained to the one before it. If any entry were altered or removed, the chain would no longer validate. Programmatic chain verification is available through the audit log API at the workspace level.
Notes and limits
- Project audit entries are permanent. There is no way to clear or prune the log, and logs are retained indefinitely.
- The project audit log is not an activity feed for individual work items. For the history of a specific work item, use that work item's activity view.
- Project audit entries also appear in the workspace audit log, which a workspace admin can use to review activity across every project at once.
- The tracked event set expands over time as coverage grows.
Frequently asked questions
Can a project admin delete an entry to hide an action? No. The log is append-only and enforced at the database level. No one, including workspace owners, can edit or delete entries.
Do login events show up in the project audit log? No. Sign-in and authentication events are recorded at the instance level, not in the project or workspace audit log.
Does viewing the project audit log show up in the log? Yes. Searching and exporting the log are recorded as events, so access to the log is itself accountable.
Who can see the project audit log? Project Admins, plus Workspace Admins and Owners. It is hidden from members and guests.