Audit log
Who did what in the organisation, when and from where — refusals included. Viewing, filters, export and integrity checks.
The audit log is an immutable record of everything that happened in the organisation: who signed in and from where, who changed a member’s permissions, who sent a task into work or approved a publication, what the pipeline did, what the platform operator did with your organisation. Refusals are recorded too — a wrong password, an attempt to act without the permission — because those are exactly what the security team looks for.
Do not confuse it with the project audit: that one analyses your codebase, while the audit log records what people and the system did in the service.
Where to find it
Settings → choose the organisation → the “Audit log” section. Each organisation has its own section: what you see relates only to the selected one.
Who can see it
- The organisation owner — always.
- A member with the “View and export the audit log” permission — a separate permission that is not part of any default role, not even Maintainer: the log contains the addresses and browsers of all members, so access to it is granted explicitly. It usually goes to a security officer or a compliance specialist — they can read the log without becoming the owner and without getting permissions on tasks.
Other members cannot open the section: the server refuses, and that refusal also goes into the log if the member was trying to export.
What an entry contains
| Field | What it means |
|---|---|
| Time | The moment of the event, to the microsecond, in UTC; the interface shows it in your time zone. |
| Who | The actor: a member’s login, a connector identifier, “operator” (a platform employee) or “system” (the pipeline). |
| Session | The identifier of the session in which the member acted — it shows that several actions were done within one sign-in. |
| From | The IP address and browser (User-Agent) of the connection, as our perimeter saw them. Not as the browser claims: the address is filled in by our server from the incoming connection, and the client cannot forge it. |
| Event | A code of the form category.action (for example, member.grant_set) and a readable description (“Permissions of member alice changed”). The full list is in the event catalogue. |
| Target | What the action was aimed at: task #35, member alice, repository shop-web, a connector. |
| Project | The development project, if the action relates to a project. |
| Operation | The class of action: create, modify, remove, access, authentication, transfer, execute. |
| Severity | info → notice → warning → critical. A refused sign-in is a warning; a change of owner or the revocation of a connector is critical. |
| Result | Success or failure; for a failure — the reason, in the wording the person saw. |
| Details | The structured parameters of the action: which permissions were granted, which decision was made, how many rows were exported. |
| Hash | The hash of the entry and the hash of the previous one — the links of the integrity chain. |
Secrets never go into the log. Saving a repository token is recorded as a fact (“credentials of repository shop-web saved”), but neither the token value nor its fingerprint is in the log. Credentials in repository addresses are stripped before recording.
How to read it
Expand a row to open the full entry: all the fields from the table above, the details in JSON and both hashes.
Filters are applied on the server, so they work across the whole log, not just the loaded page:
- Period — “Today”, “7 days”, “30 days”, “All time” or two dates in dd.mm.yyyy format (bounds inclusive).
- Actor — a list of everyone who has ever acted in the organisation.
- Result — all, successes only, refusals only. “Refusals” for the week is the quickest way to see who tried to do something they are not allowed to.
- Categories — sessions and sign-in, members and permissions, tasks, review, connectors and so on; you can pick several.
- Search — by description, target, actor, event code, address, refusal reason and details.
The log is shown in pages of a hundred entries; the “Show more” button continues the list to the end. New events appear without a reload.
What is recorded and what is not
Every action is recorded — everything that changes the organisation’s state or concerns signing in — and every refusal of such an action. The full list by category: Event catalogue.
Reading is not recorded: opening a task, viewing a diff, the list of members. The exceptions to this rule are actions on the log itself: export and integrity checks are always recorded (as is an attempt to export without the permission). Routine background operations are not recorded either if they succeed: session renewal, a connector’s periodic report; their refusals are recorded, because a refused session renewal is a sign of a revoked or stolen token.
Pipeline actions (task closed, merge conflict, review ready, machine rented) are recorded as system events. Actions of the platform operator on your organisation — topping up and adjusting the balance, disabling a connector — are recorded as operator events: you see what we did to you.
Retention
Log entries are never edited or deleted — neither by a user nor by the operator. The log is kept for the whole life of the organisation, with no depth limit: no 90- or 180-day window, no cap on the number of entries. Each entry is linked to the previous one by a hash, so an entry cannot be inserted, changed or removed after the fact without it showing — see Integrity.
What next
- Event catalogue — all codes with their description, operation and severity.
- Export and integrity — CSV and JSON Lines, the format, checking the chain with your own tools.
- Permissions reference — how to grant a security officer the permission for the log.