Skip to main content
Settings → Audit log records every change to your organisation’s configuration, with who made it and when. It is append-only. An entry is written after the change it describes has succeeded, and a database trigger rejects any attempt to change one afterwards — including from the application’s own connection, which owns the table and would otherwise be exempt from a grant. Entries are removed only by removing the organisation itself, which takes its log with it. That is the one deletion the guarantee allows, and it is stated rather than implied: a trigger cannot tell an organisation being deleted apart from someone deleting a single inconvenient row, so the promise made here is the one it can keep — an entry cannot be changed.
That ordering has a consequence worth knowing: the log can under-report and can never over-report. If writing an entry fails, a line is lost. No line can ever describe something that did not happen. For a security record that is the correct direction to fail — a gap is a gap, but an invented line is worse than no log at all.

​
What is recorded

Every entry names its actor and its subject as they were when the change was made, not as they are now. A member can be deleted afterwards, and “removed by <deleted user>” is not an audit trail. Any member can read the log, not only admins. A log that only admins can read cannot be used to check on an admin.

​
What is deliberately not recorded

The log covers configuration, not activity. Each of these is left out for a reason, and the pane says so rather than letting its silence be read as absence:
  • Triage decisions. Accepting a risk, dismissing a finding or snoozing one is already recorded against the finding itself, with its actor and its reason — see Finding triage. Two logs of the same fact can disagree, and the one that disagrees is the one nobody trusts.
  • Scans, findings and fix pull requests. Things Pipefort did, rather than changes someone made. They have their own pages, and burying configuration changes underneath them is how an audit log stops being read.
  • Your Slack notification settings. Those belong to your account, not to the organisation. Putting one person’s webhook into a record everyone in the org can read would leak a private setting into a shared one.

​
When the log opened

Each organisation records the date its log started, separately from the entries themselves. Without it, an organisation a year old and a log that opened this morning produce the same empty list — and an empty audit log reads as “nothing has ever been changed here”, which is the most misleading thing this feature could say. So an empty log states its own start date:
Nothing has been changed since 17 May 2026. That is when this log opened. Anything changed before it happened without being recorded.
Organisations created after the log existed open theirs at creation. Ones that predate it open theirs at the moment the feature was installed, never backdated to their creation — backdating would claim entries that were never written.