Audit log

The Audit log is the per-event record of activity in your tenant. Every action that matters — a schema saved, a connection added, an API key minted, a member invited, a sign-in attempt — lands here with the actor, the request path, the outcome, and a timestamp.

It’s the page you reach for when something unexpected happens and you need to know what changed. It’s also the page security and compliance teams export from during an audit cycle.

Note

Audit log access is Team tier and above. Starter tenants can upgrade later and see history back to the start of the retention window.

What’s audited

Events are grouped into categories, which is also how you filter them:

Governance. Schemas uploaded, edited, deleted or bound to a connection. API keys created and revoked. Members invited and invites accepted.

Security. Cube access denied by an ACL, rate limits exceeded, and connection tests blocked as SSRF attempts.

Connections. Warehouses created, deleted, and credentials rotated. Connection tests, both passing and failing. File datasources created and reaped.

Files. Uploads, downloads and deletions, plus the profiling runs that read a warehouse or file to draft a cube.

Agent activity. Every query against a cube — the path, the key or user that issued it, the duration, the status — split by whether it arrived over MCP, direct API, or schema discovery. On a busy tenant this is most of the log.

System. Tenant purges.

Caution

Sign-in activity is not audited. There are no login, logout or failed-sign-in events today, so the audit log won’t answer “who signed in last Tuesday” or “were there failed sign-in attempts” — a common question in a security review, and worth knowing before you’re asked it. Identity is handled by WorkOS, so that’s where sign-in history lives for now.

What’s not logged either way: query result contents (we never log the rows you fetched), per-cell access patterns, or your clicks in the Saiku UI. For the full data-handling picture see Tenant isolation.

Filtering

The log opens on the last 24 hours. Widen or narrow it with the filter bar:

• From / To — the date range.
• Category — Governance, Security, Connections, Files, Agent activity, System, or Other. The fastest way to cut a noisy log down to the class of event you’re chasing.
• Actor — the user or API key responsible.
• API key id — narrow to one specific integration.
• Outcome — success or failure.

Set what you want, then click Apply filters. Nothing re-queries as you type, which is what keeps a busy log usable. Filters land in the URL, so a particular view is something you can bookmark or paste to a colleague.

Each row shows the time, the actor, the event and its category, the target, and the outcome. Click one and a details panel opens underneath the table, carrying the event kind, the actor’s display name and email, the request ID, and then the raw event summary — HTTP method, path, status code and latency.

That request ID is the useful part: it’s the same one threaded through the server logs, so it’s what turns “something failed at 14:32” into a specific trace. Close dismisses the panel.

CSV export

Download CSV exports the currently-filtered set. Useful for offline analysis, for attaching to a SOC 2 readiness package, or for feeding your own SIEM. There’s no export-specific limit beyond your account’s overall rate limit — pull as often as you need.

Retention

How far back we commit to keeping your history available:

Tier	Window
Team	90 days
Business	Up to 7 years
Enterprise	Custom

That’s a floor, not a ceiling — it’s what we guarantee you can still query, not a promise that anything older has been destroyed. Nothing is auto-deleted today. If your compliance posture requires audit events to be purged on a schedule rather than merely retained, that’s a conversation to have with us (legal@saiku.bi) rather than something the tier gives you automatically.

Going the other way — if you need history for longer than your tier commits to, export on a schedule (daily or weekly) into your own archive: S3, GCS, a SIEM, whatever you already run. Deleting your tenant purges everything, audit history included; see Account.

Common investigations

A few patterns we see often:

“Why is this cube broken?” Filter to the Governance category. Schema edits and uploads live there, so the most recent one tells you when the definition last moved.

“What has this contractor been doing?” Put their name or email in the Actor box and skim. Worth doing before you revoke anything, so you know what you’re about to interrupt.

“Is this API key compromised?” Put the key’s UUID in the API key id box and narrow the range to the last day. You’re looking for paths it has no business touching, error spikes, or volume out of its usual pattern.

“Did somebody get refused?” Filter to Security. Denied cube access and rate-limit rejections both land there — the two events that mean somebody asked for something they weren’t allowed.

Related

• Members — actors you’ll see on this page.
• API keys — actors you’ll see on this page.
• Tenant isolation — what we log, what we deliberately don’t.