Audit log
What is recorded, what each entry contains, who can read it, and what it deliberately does not include.
The audit log records significant actions against your organisation and your services, including refused attempts. It is append-only: the database refuses any update, delete or truncate of the table that holds it.
You read it on the Security screen, and per service on that service's Activity tab.
Read it
- Open Security in the sidebar. Entries are newest first.
- Filter by action, by outcome, or by who acted: a person, Balta staff or the platform.
- Search across the action, the email address, the target, the reason and the IP.
- Press the CSV control to download the rows you have filtered down to.
For one service, open the service and select the Activity tab instead.
What is recorded
- successful sign-ins, against the organisation the session opened in
- service lifecycle: creation, plan and storage changes, restores in place or to a new service, deletion
- credential actions, including reveal and rotation
- member and role changes, invitations and ownership transfers
- billing changes: plan changes, cancellation and the payment method
- security policy, IP allowlist and parameter changes
- logical databases created or deleted
- exports
- staff access to your services, from the grant being issued to it being revoked
A refused attempt is recorded with the result denied, as fully as a successful one.
Some account events are recorded against your account rather than an organisation. Failed sign-ins, sign-outs, second-factor enrolment, password resets, email verification and revoked sessions are in that group, and the organisation log does not show them.
What an entry contains
| Field | What it holds |
|---|---|
| Who | A person in your organisation, by email address; Balta staff; or the platform |
| What | The action, such as service.credentials.rotate |
| On | The resource type and its identifier |
| When | Stored in UTC, shown in your timezone |
| From where | The IP address the action came from, and for a sign-in, the browser's user agent |
| Result | succeeded, denied or failed |
| Reason | For staff access, the reason recorded when access was granted |
A staff entry does not name the staff member. You learn that support was in your data, when, and under what reason, without being handed an employee's identity.
Some entries also carry structured detail. A plan change records the plan and storage requested, a role change records the new role, and a parameter change records which parameters changed. Others record only that something changed: an allowlist change records how many rules there are, and a security policy change records nothing more. An entry never records a copy of the data inside your database.
What it does not contain
Your query text with parameter values, and the contents of your database. An entry whose detail carries a key or a value that looks like a credential is refused rather than written.
Who can read it
| Role | What they see |
|---|---|
| Owner, administrator | The whole log |
| Viewer | The whole log |
| Developer | Their own actions only |
| Billing | Nothing. The role cannot read it |
What you will see
Entries newest first, each one a row of who, what, on what, when, from where and the outcome. The CSV carries the same columns, quoted to RFC 4180, so a reason containing a comma survives the trip to whoever asked you for it.
The dashboard loads the most recent page of entries. The filters, the search and the CSV all work over what is loaded.
Transactional guarantees, and where they stop
Allowlist and parameter changes commit in the same transaction as their entry: if the entry is not written, the change did not happen.
Sign-ins, service upgrades and security policy changes are written afterwards. A failed write there leaves the action standing and its entry missing. That is a narrower guarantee and it is stated rather than implied.
Retention
The Privacy Policy sets a retention period for security and audit logs. That period is awaiting legal sign-off, and the policy marks it as not implemented: nothing deletes an audit entry, at any age. Because entries hold IP addresses, that is personal data with no end date, and the Privacy Policy says so.
Troubleshooting
A developer cannot see an action a colleague took. That is the role. A developer reads only their own actions.
An action you took is not in the log. Check the actor filter, and check whether it is an account event rather than an organisation one. Failed sign-ins, sign-outs and enrolment are recorded against your account.
You need a date range. Filter to what you want, take the CSV, and do the date work in whatever you already use for it.
A staff entry has no name on it. By design. The reason the access was granted for is recorded instead.