> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pipefort.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Audit log

> An append-only record of who changed this organisation's configuration.

**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**.

<Note>
  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.
</Note>

## What is recorded

| Change                                          | Entry                                                                                                    |
| ----------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Renaming the organisation                       | `org.renamed`, with the old and new name                                                                 |
| Promoting or demoting a member                  | `member.role_changed`, `member → admin`                                                                  |
| Removing a member, or a member leaving          | `member.removed` — the two are distinguished, because they are the same operation and not the same event |
| Inviting, revoking an invitation, accepting one | `invite.created` / `invite.revoked` / `invite.accepted`                                                  |
| Changing the pull-request gate                  | `pr_gate.updated`, with the whole policy on both sides                                                   |
| Turning a rule off, on, or back to its default  | `rule.changed` / `rule.reset`, naming the rule                                                           |
| Turning repository monitoring on or off         | `repo.monitoring_changed`                                                                                |

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](/webapp/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.