Audit log

arcodash keeps an append-only audit log of administrative and security-relevant actions in your organization. Reading it requires admin access.

What’s recorded

Every event carries:

Field	Meaning
action	What happened, e.g. user.disabled, group.role_attached — see the table below.
user_id	Who did it. null for system-driven events, or a failed login where the account couldn’t be identified.
object_type / object_id	What it happened to, e.g. "group" / 42. null only for a failed login, which has no identified target.
additional_properties	Action-specific detail as JSON — for example, group.member_added records the user_id that was added.
created_at	When it happened.

Actions recorded today cover the administrative object types:

• Users: user.invited, user.invitation_resent, user.updated, user.disabled, user.enabled, user.api_key_regenerated
• Groups: group.created, group.updated, group.deleted, group.member_added, group.member_removed, group.data_source_assigned, group.data_source_removed, group.data_source_access_restricted_set, group.role_attached, group.role_detached
• Roles: role.created, role.updated, role.deleted
• Data sources: data_source.created, data_source.updated, data_source.deleted
• Monitors: monitor.created, monitor.updated, monitor.deleted, monitor_acknowledged, monitor_state_changed, monitor_escalated
• Notification destinations: destination.created, destination.updated, destination.deleted
• Queries: execute_query, execute_query_failed, cancel_query_execution
• Embeds and public links: embed_created, embed_revoked, embed_public_paused, embed_public_resumed

What’s not recorded

The audit log is not a complete history of every change in your organization. Notably absent:

• Sign-in activity — signing in, signing out, and failed sign-in attempts produce no audit entry. Neither does accepting an invitation or creating an organization.
• Dashboard changes — creating, editing, or publishing a dashboard’s layout and widgets produces no audit entry.
• Query changes — editing or publishing a query’s SQL, parameters, or schedule produces no audit entry.

If your evaluation needs an authentication trail, or a full change history for dashboards or queries specifically, the audit log as it exists today won’t provide one — Versions, drafts, and publishing gives you a query’s own version history, but that’s per-query, not a searchable organization-wide log.

Filtering

The audit log is paginated (page, page_size — capped at 250 per page, 25 by default) and can be filtered by any combination of:

• user_id — everything one person did.
• action — every occurrence of a specific action, e.g. all group.role_attached events.
• object_type — every event against a given kind of object, e.g. all "data_source" events.

Combine filters to narrow further — user_id + object_type answers “what did this admin do to data sources,” for example.

Where to go next

• System status — the operational counterpart to the audit log, for what’s happening right now rather than what already happened.