Overview
ORCA writes an immutable audit log entry every time something security-relevant happens in your workspace — logins, file uploads, jobs, configuration changes, key rotations. Entries are append-only: there is no API or UI path that can delete or modify them after the fact. This is the system of record auditors and compliance teams ask about. It’s also the first place to look when something unexpected happens in your workspace and you need a clean answer to “who did what, when.”What gets logged
Every entry stores the event code, the acting user (if any), the source IP, a timestamp, and a JSON metadata payload describing the action. The events ORCA always records:
The list is enforced in code — security-critical events cannot be silently dropped, and the project security rules explicitly forbid removing audit calls from any of the events above.
Properties
- Append-only. No update or delete operation exists on the
audit_logtable. The schema enforces this at the database level. - Org-scoped. Every entry is stamped with
org_idand the API only returns entries belonging to the requesting user’s organisation. Cross-tenant access is impossible by design. - Admin-only. Reading audit logs requires the
adminrole. - Best-effort write. The audit logger is designed to never raise — a failure to write a single audit entry never breaks the action being audited. Write failures are logged but not propagated.
Viewing audit logs
In the web app, open Settings → Audit logs (admin only). The viewer supports:- Pagination — 50 entries per page by default, configurable up to 200
- Event filter — narrow to a single event code, e.g.
login_failed - User column — joined from the user table, so you see emails not UUIDs
API
limit is capped at 200 entries per request. Use offset to paginate through larger result sets.
Common queries
Retention
Audit logs are retained for the lifetime of the organisation by default. They are not deleted by the data retention worker — that worker only handles uploaded customer files, not security records. If your compliance posture requires log archival to a customer-controlled bucket (e.g. for SIEM ingestion), contact support — we can configure scheduled exports to S3 or webhook delivery.Tips
- Pull audit logs into your SIEM. The endpoint is paginated and stable; a small cron that polls
?event=login_failedand forwards to Splunk/Datadog gives you alerting without any custom integration. - Audit before debugging. Before investigating a “weird state” complaint, pull
event=*for the affected user’s email and look for a manual config change you forgot about. - Pair with API keys. Every API key use creates an
api_key_usedevent with the key prefix in metadata, so you can reconstruct exactly what an integration did.
What’s next?
- API keys — manage and rotate the keys whose usage shows up here
- Security overview — the broader compliance picture
- Data retention — control how long uploaded files are kept (separate from audit retention)