Audit log
The audit log is a record of who did what on your site. It is for site administrators who answer security and compliance questions. Project administrators can use it to see what happened in their own projects.
The log is append-only: it refuses updates and deletes. Each event is written in the same transaction as the change it describes, so a change cannot happen without its record.
Who can read it
Section titled “Who can read it”| Role | What they can read |
|---|---|
| Site administrator | Every event on the site |
| Project administrator | The events of the projects they administer |
| Anyone else | Nothing. The request is refused. |
Project administrators choose the project when they read the log. In the web application, the audit section of site administration shows the log.
What is recorded
Section titled “What is recorded”Every event belongs to one of five categories: identity, configuration, access, automation and integration. The log covers:
- Sign-ins: failed, refused and successful, and sign-outs.
- Accounts, passwords and sessions.
- Roles in projects and groups, and invitations.
- Configuration changes, with what changed. Secrets are redacted.
- Notification schemes, form sharing, work item security, archive and redaction.
- Exports and imports.
- Automation rules and agent grants.
- API tokens: creation and revocation.
Exporting the log is itself recorded, see below.
What an event contains
Section titled “What an event contains”| Field | Meaning |
|---|---|
| Time | When it happened |
| Category and event | For example auth.login_failed |
| Actor | A person, an agent, the system or someone anonymous, with a name |
| Project | The project concerned, if there is one |
| Target | The kind and name of what was changed |
| Summary | A one-line description |
| Changes | Each field with its old and new value |
| Details | Extra facts about the event |
| Address and client | The IP address and the user agent of the request |
Filter and page through events
Section titled “Filter and page through events”Events are listed newest first. Narrow them with these filters.
| Filter | What it matches |
|---|---|
| Category | One of the five categories |
| Event | An exact event name such as auth.login_failed, or a family that ends in a dot such as project. |
| Person | The actor |
| Project | One project |
| Item | The target of the change |
| Text | The summary, actor, project, target and IP address |
| From and to | A start and an end. A date as the end covers that whole day in UTC. |
A page holds 1 to 200 events, 50 by default. A cursor from the previous page takes you to older events. A bad filter is refused with a clear error.
The filters are query parameters of one request. This one lists failed sign-ins since the start of November:
GET https://acme.orbit.inortix.com/api/v1/audit?action=auth.login_failed&from=2026-11-01&limit=100The API reads the log as a signed-in person. A personal API token never has site administration. See API authentication for what tokens can do.
Export to CSV
Section titled “Export to CSV”Export the events that match your filters as a CSV file.
- The export takes the same filters as the list and holds up to 10,000 events.
- The file is UTF-8 with a byte order mark and has 16 columns.
- Cells that a spreadsheet could run as a formula are neutralized.
- The file is named
orbit-audit-<yyyymmdd-hhmm>.csv.
The export is itself audited. Before the file is produced, Orbit records an audit.exported event with the number of rows, a digest of the file and the filters used.
Retention Planned
Section titled “Retention ”How long events are kept will depend on the plan. The periods are on the pricing page. Plan limits are not applied yet.